Verifying fixes: recrawl, Search Console and logs

0:00 Verifying fixes

A ticket isn't done when the pull request merges. It's done when production behaves as specified, and search engines have processed the change. In this lecture you'll verify Kiran Home's fixes in three layers: production behaviour on the same day, Google's processing over days to weeks, and behaviour change in the logs over weeks. You'll also learn how to diagnose a fix that didn't work, and how to record verification so nobody has to take your word for it.

0:34 Layer 1: production (same day)

Layer one: production behaviour, the same day. Use the same crawl configuration you saved in Module one, and list-crawl the affected URLs in production. For RC one, the canonicals, the check in the lesson text loads the production crawl export, keeps product and journal URLs, and counts those whose canonical doesn't equal their address, writing the first twenty failures to a file. For RC three, the redirects, recrawl the legacy list and confirm one three-oh-one to a relevant two-hundred page, no chains in the priority tier, and four-tens only on the agreed list.

1:14 Layer 2: Google (days–weeks)

Layer two: Google's processing, over days to weeks. Use URL Inspection on a sample of fixed URLs, with a live test to confirm Google sees the new canonical, and request indexing for a handful of key pages only; it's rate-limited and not needed for thousands of URLs. In the Page indexing report, use Validate fix for the relevant issue type once the fix is live. Validation can take a couple of weeks or longer on big sites. Resubmit updated sitemaps. Watch enhancement reports for structured data, and remember Core Web Vitals field data updates on a twenty-eight-day window.

1:57 Layer 3: logs (weeks)

Layer three: behaviour change in the logs, over weeks. After RC two, Googlebot requests to sort, price and size URLs should fall sharply once the robots rules are fetched, and product URLs should become a larger share. After RC four, previously uncrawled deep products should start appearing. After RC three, hits on legacy four-oh-fours should decline. The hands-on in the lesson text turns the weekly segment table from the log lab into a share-of-crawl area chart, with dashed lines for each release. It's the most persuasive visual in your stakeholder report.

2:37 Verifying RC8

Verifying RC eight, the bot access fix, needs its own checks. Request product URLs with the bots' user agents to confirm no challenge page, knowing that's only header simulation. Check the CDN firewall events for verified Bingbot and AI search bots: challenges on public paths should drop to zero. And in Bing Webmaster Tools, indexed product counts should recover over the following weeks, and AI Performance citations may reappear.

3:07 Regression watch

Set up a regression watch for the first months, because fixes regress when unrelated code changes. Run a weekly scheduled crawl of a fixed URL sample per template and diff it against the post-fix baseline. Alert if any product canonical differs from its address, if any noindex appears on product or category templates, or if robots.txt changes. The change monitor from the Technical SEO Mastery course does exactly this.

3:37 When a fix 'doesn't work'

What if a fix didn't work? Diagnose with the pipeline. Production correct, but Google still picks the old canonical? Check for conflicting signals, like internal links, sitemaps and hreflang pointing elsewhere, and check the last crawl date in URL Inspection. Validation failed on some samples? Open every failed URL, because it's often an edge case: uppercase URLs, trailing slashes, or a second template variant. Log behaviour unchanged? Confirm which robots.txt Google fetched, and that internal links to the blocked patterns were actually removed.

4:13 Example 2: the uppercase edge case (illustrative)

Worked example two, a different client, illustrative. A Jeddah retailer's validation for duplicate, Google chose different canonical than user fails on a third of the samples, a month after a canonical fix. Opening the failed URLs reveals a pattern: they're all uppercase variants, linked from an old email template, still returning two hundred with a self-referencing canonical. The fix: redirect uppercase paths to lowercase, and correct the email template. Validation passes on the next attempt. The failure wasn't the fix. It was an edge case nobody had listed.

4:51 The verification record

Close each ticket with a verification record. For example: SEO seven verified on a date. The production crawl, using config version one point two, found zero of twelve thousand three hundred product URLs non-self-canonical. Search Console validation started the next day. Ten of ten sampled URLs show Google-selected canonical equal to user-declared, checked two weeks later. And evidence files attached. Anyone can re-check your work from that record.

5:21 Watch me do it: verifying RC1

Watch me do it. I'll verify the RC one canonical fix, layer by layer. Day zero, layer one: I load crawl config version one point two and list-crawl twelve thousand three hundred product and journal URLs in production. I run the check script. Zero URLs not self-canonical. I spot-check the raw HTML of three URLs with curl to confirm the canonical is server-rendered. Day one, layer two: in URL Inspection, I test live three UAE products. Google sees the self-referencing canonical. In Page indexing, I open alternate page with proper canonical tag and click Validate fix. I resubmit the UAE and Pakistan product sitemaps. Day fourteen: validation shows passed for most samples, with six failures. I open each failed URL. All are uppercase variants linked from an old promotional email. I ticket a redirect from uppercase to lowercase. Day twenty-one, layer three: I rerun the log lab's weekly chart. The product share of verified Googlebot requests is growing, and UAE product URLs are being crawled again. Day twenty-eight: URL Inspection on ten sampled URLs shows Google-selected canonical equals user-declared. I close the ticket with the verification record, including the config version and evidence files.

6:45 A realistic timeline (illustrative)

Let me give you a realistic timeline for Kiran Home, so you can set expectations with stakeholders. Day zero: RC one and RC eight go live, and the production crawl confirms them the same day. Days one to three: URL Inspection live tests show Google sees the new canonicals, and CDN events show zero challenges for verified bots. Weeks one to three: Page indexing validation progresses, and logs start showing product share rising. Weeks two to six: non-UK product pages move to indexed, and Bing's product coverage recovers. Core Web Vitals changes show up only after the twenty-eight-day window rolls over. Sharing this timeline up front prevents panicked messages in week one.

7:34 Mistakes, recap, try this now

Common mistakes. Verifying on staging only. Requesting indexing for thousands of URLs manually instead of fixing signals and sitemaps. Declaring victory from one URL Inspection sample. And forgetting that Core Web Vitals field data lags by weeks. Recap: production the same day, Google over days to weeks, logs over weeks, a regression watch, and written verification records. Try this now: pick one fix your team shipped recently, and write a three-layer verification record for it.