Checklist
How do you re-test after a GPC or Reject All fix?
Re-test a GPC or Reject All fix on the same URL and consent label. Diff that host before and after. A free US-baseline scan is not an EU or California result.
In brief
After a GPC or Reject All fix ships, re-test the same URL under the same consent label as the original finding. Save a new request, cookie, and screenshot pack, then diff the host that failed. Reject All passes when those marketing hosts and cookies stay absent or gated. GPC-on passes when Sec-GPC is present and the network no longer matches GPC-off. A CMP dashboard does not close the ticket. A free US-baseline re-scan is not an EU or California conclusion.
Not legal advice
This article explains how to re-test a storefront after engineering ships a fix for Global Privacy Control or Reject All behavior. It is not legal advice, not a compliance certificate, and not a guarantee that a passing re-test meets GDPR, CPRA, ePrivacy, or any other rule. ConsentProbe reports are technical observations. They do not replace counsel.
Last updated September 24, 2026. The artifact rules live on the cookie consent evidence pack guide. The GPC file list lives on the proof checklist. This page is the verification loop after the fix is on the URL you will hit.
Short answer
After engineering ships a GPC or Reject All fix, re-test with the same consent-state label and the same storefront URL as the original finding. Capture a fresh request, cookie, and screenshot pack, then diff before versus after for the host that failed.
For Reject All, a pass means marketing hosts and marketing cookies that fired before the fix stay absent or gated after Reject on the re-run. For GPC-on, a pass means you still have Sec-GPC: 1 header proof, and the post-fix network and cookie diff shows the gated behavior you expected. A file that still matches GPC-off is still a fail. Do not close the ticket from a CMP dashboard alone. Package artifacts like a cookie consent evidence pack, and update the ticket's expected versus observed fields. ConsentProbe can re-scan under the same labels with findings linked to those surfaces. A free US-baseline re-scan does not prove EU Reject or California GPC behavior. This page is verification guidance, not legal advice and not a compliance certificate.
Re-test under the same label
A fix aimed at Accept All gating can leave Reject All or GPC-on broken. Fresh, Reject, Accept, and GPC-on are different files. A pass on Accept does not update the Reject row, and a pass on Reject does not update the GPC-on row.
A free US-baseline re-scan does not close an EU Reject ticket or a California GPC ticket. The free versus paid guide states that split. Use the same URL, the same button text or the same GPC setup, and the same surfaces as the original finding.
Copy the consent state, the URL, the host, the expected versus observed lines, and the artifact IDs off the ticket before you touch the browser. The evidence pack guide is the field list for those artifacts. The re-test fills the after side of the ticket.
Verification loop
Keep the after pack comparable with the before pack. A new profile, a new click path, or a preview URL that is not the ticket URL produces a different test.
- Open the original ticket: consent state, URL, host, expected versus observed, and artifact IDs.
- Confirm the change is live on the URL you will hit. A theme or app version note helps when you have it.
- Use a clean profile and reproduce the same state: the Reject All click path, or GPC-on with a
Sec-GPCheader check. - Capture request, cookie, and screenshot evidence again, using the evidence pack rules.
- Diff before versus after for the named host. Update the ticket with the after pack.
- If other hosts still fail under that label, open new tickets. Do not bury them in a thread marked fixed.
What a pass looks like
Pass, on this page, means the named host changed under the same label.
| Label | Observable pass | Still failing |
|---|---|---|
| Reject All | Marketing or ad hosts from the original finding are absent or gated after Reject. Marketing cookies for those vendors are not newly set. | The same host fan-out as Accept, or as the before pack. |
| GPC-on | Sec-GPC: 1 is confirmed. The network and cookie diff versus GPC-off shows the expected drop or gate for the named hosts. | The header is missing, or Network matches GPC-off or the before pack. |
| Either label | The finding sentence cites the after artifact IDs, and the CMP UI claim matches Network. | The dashboard says blocked while Network still loads the host. |
Diff the named host first
Start with the host written on the ticket. Then scan sibling pixels for a regression. Keep one navigation path, for example home and then one collection, on both the before file and the after file. A different template makes the diff argue about the page, not the fix.
Illustrative sketch, using stand-in hosts: under Reject All, the before file shows ads.example requesting /collect and a cookie named adv_id. The after file, same URL, same Reject control, same navigation, shows no request to ads.example and does not set adv_id. That is an observable pass for ads.example. If ads.example still loads, leave the ticket open and attach the after pack. If metrics.example appears only on the after file, open a new ticket.
For GPC, keep header proof in the before pack and in the after pack. The GPC proof checklist says what each file should hold. Diff the after GPC-on file against a fresh GPC-off run, not only against the old failure. A fix can gate the old host and leave a sibling pixel looking like the GPC-off visit.
Reject All diagnosis stays on the Reject All leftovers guide. Shopify Reject All steps stay on the Shopify Reject All guide. Shopify GPC steps stay on the Shopify GPC honor test. This page compares the new capture with the old one. A re-test against a preview URL that is not the ticket URL does not close the finding on the URL in the ticket.
Re-scan under the same labels
When hand-built before and after packs are slow, re-run ConsentProbe under the same labels: Fresh, Reject, Accept, and GPC where that signal applies. Findings stay linked to a request, a cookie, or a screenshot, so the after file can sit next to the before file.
A free US-baseline visit is the format pass. Use paid EU scenarios when the original claim was EU Reject or Accept. Use paid California or GPC scenarios when the original claim was GPC. The free versus paid guide states that split. ConsentProbe does not install a CMP or a banner.
FAQ
How do you re-test after a GPC or Reject All fix?
Use the same consent label and the same URL as the ticket. Capture new request, cookie, and screenshot artifacts, then diff the named host before versus after.
What does a Reject All pass look like?
Marketing hosts and marketing cookies from the original finding stay absent or gated after Reject on the re-run. The same fan-out as the before pack means the ticket stays open.
What does a GPC-on pass look like?
Sec-GPC: 1 is still on the navigation request, and the network and cookie diff no longer matches GPC-off for the named hosts. The proof checklist lists the files.
Can I close the ticket from the CMP dashboard alone?
No. Require Network and cookies under the same label. The CMP claims guide and the GPC versus CMP claims guide cover a blocked badge with the host still loading.
Does a free US re-scan prove an EU Reject or California GPC fix?
No. A free US-baseline visit is not an EU Reject conclusion or a California GPC conclusion. See the free versus paid guide.
Is a passing re-test a compliance certificate?
No. It is a technical verification of the labeled visits you re-ran. It is not legal advice and not a substitute for counsel.
Limits of this page
This page explains how to re-test after a GPC or Reject All fix. It is not legal advice, not a compliance certificate, and not a guarantee that a passing re-test meets GDPR, CPRA, ePrivacy, or any other rule. A closed ticket is a technical file update. ConsentProbe reports stay tied to requests, cookies, and screenshots. A free US-baseline re-scan is not an EU Reject or California GPC conclusion.
Related guides
Use the evidence pack for artifact rules, the ticket guide for the field list on the engineering ticket, the Reject All guide for the first diagnosis, and the GPC proof checklist for header, diff, and screenshot files.
- How do you turn a cookie audit finding into an eng ticket?
- What belongs in a cookie consent audit evidence pack?
- Reject All Still Tracking: What to Check After You Say No
- What is Global Privacy Control, and how do you test it on a storefront?
- GPC vs CMP Claims: How to Spot a Mismatch
- How do you prove a storefront honored GPC?
- What does a free US-baseline cookie audit prove vs paid EU or California scans?
- CMP claims vs runtime evidence: how do you prove the banner actually works?
- How do you test a Shopify cookie banner's Reject All button?
- How do you test whether a Shopify storefront honors Global Privacy Control?
- Which cookie consent test should you run first?
- Reject All vs Accept vs GPC: A Scenario Matrix for Shopify Stores
- ConsentProbe methodology
- Pricing and listed regional products
Sources
These links cover the platform and regulatory context used in this guide. Applicability still depends on the organization and jurisdiction.
Save a US-baseline technical record
After a DIY check, run a free US-baseline audit: one browser visit outside California, with cookies, requests, and screenshots stored as evidence. That visit does not run EU reject/accept or California GPC. EU, California, and Global 2 audits can be purchased from Billing after sign-in.