Write each change as a check with a URL, an element and an expected value. Run every check on a fresh copy of the live page that bypasses the caches. Then confirm that the pages that were fine before are still fine, and rescan at the same depth as your baseline.
ITIL change control closes a change only after someone has checked that it did what was approved. Close a website change the same way. Publishing a change and verifying it are separate events. Caches, staging copies and market variants all live in the gap between them. A website change counts as verified when each written check passes on the live site at a recorded time and the pages that were fine before are still fine.
Before you start
- Take a baseline before the change. Save the raw HTML and the response headers of the pages you will touch. Keep a copy of robots.txt, the sitemap count and the structured data results. Note the Search Console status, and run a scan with its depth written down. The guide on how to save the raw HTML covers the first part.
- Make sure you can undo the change. On Shopify, duplicate the theme before you edit it, because Shopify itself recommends a backup copy before you customize. On WordPress, work in a staging copy if your host offers one, and name the backup you would restore.
- Block out time the day after the release. Step 4 needs it.
Steps
Step 1. Write each change as a check
Turn every change into a line that names a URL, the element and the value you expect. Write it so that it can fail. "Robots.txt is fixed" cannot fail, while a line that names the file, the group and the rule can.
| URL | Element | Expected value |
|---|---|---|
| https://www.example.com/robots.txt | The OAI-SearchBot group | Allow: / |
| https://www.example.com/products/blue-dress | The canonical link | https://www.example.com/products/blue-dress |
| https://www.example.com/products/blue-dress | The Offer in the JSON-LD | price 79.00, priceCurrency USD |
| https://www.example.com/old-page | Status and Location header | 301 to https://www.example.com/new-page |
Step 2. Fetch a fresh copy of the live page
Fetch each URL without cookies and with a cache buster. A cache buster is a made up query parameter, such as ?cb= followed by the time. Save the status, the final URL, the headers and the body. Fetch from a second network as well, such as a phone on mobile data. A CDN edge or a market redirect can answer one place differently from another.
curl -s -L -A "Mozilla/5.0" -D headers.txt -o body.html "https://www.example.com/products/blue-dress?cb=20260930T1400"Read the cache headers before anything else. On Cloudflare, CF-Cache-Status says HIT when the answer came from the cache and MISS when it came from your server. An Age header on a cached answer gives the number of seconds the copy has been in the cache. Edge caches can be very loyal to the version of a page you just replaced.
Step 3. Run each check against the fetched copy
Search the saved body and headers for each expected value. Mark each check as passed or failed, with the time. For markup, test the fetched HTML and not the snippet you meant to ship. The guide on how to validate structured data covers the tools.
Step 4. Give robots.txt and the sitemap a day
Record the time of any robots.txt change and test again after 24 hours. Google generally caches robots.txt for up to 24 hours. It may keep a copy longer when it cannot refresh it. OpenAI says its systems need about 24 hours to reflect a robots.txt update, and Perplexity says up to 24 hours. For a sitemap, read the last read date in Search Console and Bing Webmaster Tools the next day. The guides on how to check robots.txt and verify the sitemap have the details.
Step 5. Test one URL per template and one edge case
A fix to the product template has to hold on every product. Test one URL for each template you touched. Add one edge case as well, such as a variant URL or an out of stock product.
Step 6. Check the pages that were fine before
Run the regression checks on pages you did not mean to change. Compare the status code, the canonical link, the robots meta tag and any X-Robots-Tag header with the baseline. Confirm that the structured data still parses and that the internal links still answer 200. A diff of the baseline HTML against the new HTML shows every line that moved.
diff baseline/blue-dress.html live/blue-dress.htmlTo check canonicals, use the full method in the guide on how to inspect canonicals.
Step 7. Run the live test in Search Console
Run the live test in URL Inspection on your samples. It fetches the page in real time and shows the rendered page and the response headers. Each property has a daily limit of live inspections. Google's inspection tool does not follow redirects. Test the final address. The live test also cannot predict which canonical Google will choose.
Request indexing only for the most important addresses. Google says repeated requests for the same URL do not get it crawled any faster. Crawling can take anywhere from a few days to a few weeks.
Step 8. Rescan at the baseline depth
Run the same scan you ran for the baseline, at the same depth and with the same settings. Compare the two results side by side. A scan at a different depth reads different pages, so its score says little about your change.
Step 9. Record the result or roll back
Write down each check, its result, the time and who checked it. If a check fails and the fix is not quick, roll back. On Shopify, only one theme is published at a time. The previous theme stays on the Themes page. You can publish it again. On WordPress, restore the backup you named before the change.
Check that it worked
Every written check should pass on the live site at a recorded time. The regression list should show no new problem. The rescan at the baseline depth should show the change you expected and no other.
If it did not work
- If the fetch still shows the old page, read the cache headers. A HIT with a large Age means the CDN is serving its own copy. Purge the cache or wait for it to expire.
- If the change went to a staging copy or an unpublished theme, the live site does not have it yet. A Shopify preview link opens an unpublished theme on your primary domain, with a token in the address. Merchant preview links expire after 30 days. A check made through a preview link says nothing about the published theme. Check the published theme without the token.
- If a market or currency version differs from the page you tested, fetch the page as a visitor from each market you sell to.
- If a WordPress cache plugin serves the old page, clear the plugin's cache after each release. The WordPress performance handbook says plugins such as W3 Total Cache, WP Super Cache and Cache Enabler store pages as static files and serve those to visitors.
- If a crawler still follows the old robots.txt, give it the day from step 4 before you call the change a failure.
- If a report presents the rescan as proof that an AI answer changed, correct the report. A rescan shows what a crawler can now read. It says nothing about why an assistant picked one answer over another.
Platform notes
On Shopify, edit a duplicate of the theme and check it through its preview. Then publish it and run the checks again on the live store. Only the published theme reaches visitors and crawlers, so a passed preview check is not the end of the job.
On WordPress, whether you have a staging copy depends on your host. After you push the change, clear the cache plugin and any server or CDN cache before step 2.
On any platform with a CDN in front, read the CDN's cache status header first. Cloudflare documents every value its header can take.
What Visibility Mesh checks and what it does not
We record every change Visibility Mesh makes on a Shopify or WordPress website. The owner approves each change before it goes live, and we back it up so that it can be reversed. We check it again afterward with a scan at the same depth and with the same methodology version as the baseline scan. We treat any move in the score smaller than about 2 points as noise, because two scans of an unchanged site often land that close together. Our reports do not claim that a rescan explains an assistant's answer. The page on how our managed service checks every fix describes the whole routine. If a fix will not stay fixed, describe the problem on our contact page, and we will reply within one business day.
Questions people ask
How long does a recrawl take after I change a page?
Google says crawling after a request can take anywhere from a few days to a few weeks. For robots.txt, Google generally refreshes its cached copy within 24 hours. OpenAI and Perplexity give about a day as well. Request indexing only for the most important addresses, since repeating the request does not speed it up.
Should I request indexing after every change?
You do not need to. Google applies a quota to Request indexing. It also says repeated requests for the same URL do not make crawling faster. Use it for a handful of important pages. When many URLs change at once, submit the sitemap, which is the route Google suggests for large numbers of URLs.
How can I tell a cache from a failed deploy?
Fetch the page twice, once plainly and once with a cache buster, and read the headers each time. If only the fetch with the cache buster shows the change, a cache is serving the old copy. The cache headers show which layer answered. If neither fetch shows the change, look for a deploy that went to a staging copy or an unpublished theme.
Sources
Every page below was read on September 30, 2026.
- Google, Ask Google to recrawl your URLs, Google Search Central, last updated December 10, 2025.
- Google, How Google interprets the robots.txt specification, Google Crawling Infrastructure, last updated August 31, 2026.
- Google, URL Inspection tool, Search Console Help. The page shows no update date.
- Google, How HTTP status codes affect Google's crawlers, Google Crawling Infrastructure, last updated February 4, 2026.
- OpenAI, Overview of OpenAI Crawlers, undated, and Perplexity, Perplexity Crawlers, undated.
- Cloudflare, Cloudflare cache responses, last updated September 4, 2026.
- curl, curl man page, for the options in step 2, undated.
- Shopify, Adding, previewing, and buying themes, Shopify Help Center, undated, and Duplicating themes, undated.
- WordPress, Cache, Advanced Administration Handbook, undated.
The Academy explains why fixes come undone after theme updates and app installs.
Run the free scan, and we read five of your key pages the way an AI crawler reads them, with no card and no call.