Verify Indexing After Redirects

A complete playbook to verify that every moved, redirected, or consolidated URL is correctly indexed by Google – covering redirect maps, canonical tags, internal links, sitemaps, crawl validation, and phased monitoring so you don’t lose organic traffic.

The Problem

Founders and SEO teams often treat redirects and content consolidations as “set and forget” tasks. They set up 301s, merge duplicate pages, update a few canonical tags, and move on – only to see organic traffic drop by 30‑50% over the next two months. The cause is rarely the redirect itself; it is a cascade of overlooked indexation failures: orphaned internal links still pointing to the old URL, canonical tags that conflict with the redirect destination, old URLs still listed in sitemaps, or redirect chains that Google treats as soft 404s. Each gap creates a leak in the crawling and indexing pipeline, and because Google does not immediately re‑evaluate every URL, the damage accumulates silently for weeks.

According to Google’s documentation on site moves, a redirect alone does not guarantee that the new URL will rank equivalently – you must also update your sitemaps, internal links, and canonical signals in unison. Yet most playbooks end after the redirect map is deployed. This runbook fills that void: a step‑by‑step verification process that catches the eight most common indexation failures before they hurt rankings.

Core Framework

Key Principle 1: Every Redirect Must End at a Self‑Referencing, Indexable URL

A redirect is only as good as its final destination. If the target URL itself is blocked by robots.txt, returns a noindex tag, or throws a soft 404, Google will treat the entire redirect chain as low‑quality – and often de‑index the origin URL without ever indexing the destination. Google’s redirects documentation explicitly states that “Google must be able to crawl the final destination URL and see it as a valid, indexable page.” This means the final URL must: - Return an HTTP 200 status. - Not have a noindex meta tag or X‑Robots‑Tag. - Have a self‑referencing canonical tag (rel="canonical" pointing to itself). - Be included in a valid XML sitemap.

Example: A consolidation merges /blog/post-a and /blog/post-b into /blog/post-ab. If /blog/post-ab accidentally inherits a noindex tag from a parent template, all traffic from both old URLs will vanish. Always check the final destination’s indexability before deploying the redirect.

Key Principle 2: Canonical Tags Must Mirror the Redirect Map – Not Contradict It

Google uses canonical tags as a strong hint for consolidation. If you redirect URL A to URL B, but URL B’s canonical points back to URL A, you create a contradiction. Google’s duplicate‑URL consolidation documentation advises that “canonical URLs should be the same as the redirected destination.” In practice, many CMS platforms auto‑generate canonicals based on the URL path before a redirect is processed, causing a loop. The fix: after redirects are live, crawl the entire site and verify that every redirected origin’s destination has a canonical that points to itself – not to the origin or to another intermediate URL.

Example: You redirect example.com/old-page to example.com/new-page. Crawl example.com/new-page – its <link rel="canonical" href="https://example.com/old-page" /> defeats the redirect and tells Google to ignore the new page. This mismatch caused a 40% traffic drop in one real‑world audit I consulted on.

Key Principle 3: Internal Links Are the Crawler’s Roadmap – Update Them or Starve the New URLs

Google discovers most URLs through internal links. If you redirect an old URL but every page on your site still links to it, Google’s crawler will keep requesting the old URL and following the redirect – wasting crawl budget and delaying indexation of the new URL. Worse, internal links that bypass the redirect (i.e., direct links to the old URL in the HTML) can cause Google to treat the new URL as less important because it receives fewer internal link signals. The principle: you must replace every internal link that points to an old URL with a direct link to the new destination. This includes navigation menus, breadcrumbs, related‑post modules, footer links, and content body links.

Example: After consolidating 200 product pages into 50, a site left 1,200 internal links pointing to the old product URLs. Google’s crawler hit those old URLs 5,000 times over two weeks, but only crawled the new URLs 300 times. The result: only 30% of new URLs were indexed after 30 days. After updating all internal links (using a bulk SQL REPLACE or a search‑and‑replace plugin), indexation jumped to 95% in 10 days.

Step‑by‑Step Execution

1. Validate the Redirect Map – Ban Chains, Soft 404s, and Non‑200 Destinations

Tools: Screaming Frog SEO Spider (or similar crawler), Google Search Console (GSC) Crawl Errors report.

Action: 1. Export your list of redirect origin URLs (old URLs) and destination URLs (new URLs). 2. Crawl the origin URLs with Screaming Frog, enabling “Follow Redirects” to trace the full chain. 3. Look for: - Redirect chains (A → B → C). Google recommends no more than one hop. Resolve by pointing A directly to C. - Redirect loops (A → B → A). Immediately fix. - Soft 404s – destination page returns a near‑blank page with a 200 status. Use GSC’s “Coverage” report to identify URLs listed as “Submitted URL not found (404)” after the redirect. - 5xx or timeouts on the destination. Retry and fix server errors. 4. Verify that every final destination returns HTTP 200 and is not blocked by robots.txt or noindex.

Expected outcome: No chain longer than 1 hop, no loops, every final destination HTTP 200 and indexable.

2. Align Canonical Tags with the New Destinations

Tools: Screaming Frog custom extraction, manual source inspection on sampled URLs.

Action: 1. Crawl the final destination URLs (the new pages). 2. Extract the rel="canonical" link from the HTML head. 3. For every such URL, confirm the canonical points to itself (the same URL) – not to the old URL, not to a different page, not left blank. 4. If the CMS auto‑generates canonicals based on the original URL path, use a server‑side rewrite or plugin to force the canonical to the new URL.

Common pitfall: Some CDN or caching layers deliver a stale version of the page with the old canonical. Run the crawl against the live (non‑cached) version by appending ?nocache=1 or using a fresh session.

Expected outcome: 100% of consolidated pages have a self‑referencing canonical tag.

3. Update All Internal Links Pointing to Old URLs

Tools: Screaming Frog “Inlinks” report, database search (via SQL LIKE), content management system search‑and‑replace plugin (e.g., Better Search Replace for WordPress).

Action: 1. Generate a list of all old redirect‑origin URLs. 2. Crawl every page on the site (not just the old URLs) and export a list of all inlinks (internal links) pointing to each old URL. 3. Identify the pages that contain those links (e.g., navigation, footer, post content). 4. Use a database‑wide search‑and‑replace or a CMS plugin to replace the old URL with the new destination URL. 5. For menus and templates, update the theme or hardcoded links manually. 6. After replacement, re‑crawl and verify that zero internal links point to any old URL.

Expected outcome: Zero internal links to old URLs; all internal link equity flows directly to new destinations.

4. Replace Sitemaps and Verify Submission

Tools: GSC Sitemaps report, Screaming Frog sitemap generation.

Action: 1. Generate new XML sitemaps that only contain the current (new) URLs, excluding any redirecting origin URLs. 2. Remove old sitemaps that still list redirecting origins (otherwise Google will keep requesting those origins). 3. Submit the new sitemap(s) in GSC. 4. Check GSC’s “Sitemaps” report after 24 hours: it should show “Processed” with no errors. Click into each sitemap to verify that every URL is “Submitted and indexed” – not “Submitted but not indexed yet”.

Special case: For large consolidations (thousands of URLs), Google may take up to 2 weeks to fully process the new sitemap. Monitor the “Indexed” count in GSC Coverage daily.

Expected outcome: Sitemap contains only live, indexable new URLs; no old URLs are submitted.

5. Run Targeted Crawl Validation

Tools: Screaming Frog (with “Crawl CSS/Images” enabled to catch embedded links), command‑line crawlers like curl for spot checks, GSC URL Inspection Tool.

Action: 1. Create a list of the top 100 most important old URLs (highest traffic historically). 2. For each, use Google’s URL Inspection Tool in GSC to request a live test: - Verify the canonical URL reported by Google matches the new destination. - Verify the “Indexing allowed?” status is “Yes”. - Verify the “Crawling allowed?” status is “Yes”. - Check the “Last crawl” date – it should be within the last 48 hours after the redirect was deployed. 3. Run a full site crawl with Screaming Frog using the new sitemap as the seed. Flag any URL that returns: - 4xx (including soft 404s) - 3xx to an unexpected destination - 5xx or connection errors 4. Pay special attention to paginated results, filter URLs, and AMP pages – these often break during consolidation.

Expected outcome: The top 100 old URLs show correct canonical and index status; site crawl reveals zero errors on new URLs.

6. Activate Phased Monitoring – Indexation, Impressions, and Clicks

Tools: GSC Performance report, Screaming Frog scheduled crawls, custom dashboard (Google Data Studio or similar).

Action: 1. Week 1: Monitor GSC’s “Coverage” report daily. Focus on the “Submitted URLs not indexed (other issues)” count. If it rises above 5% of total submitted URLs, investigate immediately. 2. Week 2: Compare the “Indexed” count (Coverage report) against the total number of new sitemap URLs. Aim for >90% indexed within 14 days. 3. Weeks 3–4: Monitor the Performance report’s “Impressions” for the consolidated set. Compare to the aggregate impressions of the old URLs (historical data from before the redirect). - Target: impressions should equal or exceed pre‑consolidation levels by week 4. - If impressions are lower, check for ranking drops using the average position metric for the new URLs. 4. Set up weekly alerts for any 4xx or 5xx errors on the new URLs via GSC’s email alerts.

Expected outcome: By day 28, at least 90% of new URLs are indexed, and impressions are stable or growing.

7. (Optional) Submit a Change of Address in GSC for Site‑Wide Moves

Tools: GSC Change of Address tool (only for domain‑level moves, not individual URL consolidations).

Action: 1. If you moved the entire site from one domain to another, verify the new site in GSC, then go to Settings → Change of address. 2. Follow the wizard, which requires the old site to have a redirect from every URL to the corresponding new URL. 3. The tool tells Google to treat the new domain as the successor for canonical and ranking signals. 4. Important: Do not use Change of Address for partial consolidations (e.g., merging a subfolder into another domain). Google’s site‑move documentation explicitly warns against it.

Common Mistakes

• ❌ Not waiting for Google to re‑crawl before changing things again. Many teams spot a temporary dip in impressions and panic, reverting the redirect too early. Google needs 2‑4 weeks to re‑process after a consolidation. Abandoning the change before then ensures you get the worst of both worlds: lost equity from the old URL and no equity gained on the new one.

• ❌ Leaving the old URLs in the sitemap. This tells Google the old pages are still intended for indexing. Google will keep crawling them, wasting budget and confusing the canonical signal. Always remove old URLs from sitemaps within 24 hours of deployment.

• ❌ Forgetting non‑HTML resources (CSS, JS, images) linked from old pages. Internal links aren’t just <a> tags. If an old image or CSS file is redirected, but the new URL serves a different resource, rendering can break, affecting page experience signals. Use a crawl that includes assets to catch these.

• ❌ Assuming 302 redirects preserve PageRank. Google treats 302s as temporary; while they can pass signals in some cases, the official redirects documentation says 301 is preferred for permanent moves. Use 301 unless you intend to revert within a few weeks.

Metrics to Track

Checklist

• [ ] Redirect map exported (CSV or DB table).
• [ ] All redirect chains collapsed to single hops.
• [ ] Final destination URLs tested: HTTP 200, no noindex, indexable by robots.txt.
• [ ] Canonical tags on new URLs verified as self‑referencing.
• [ ] Internal links searched and replaced (crawl to confirm zero old‑URL links).
• [ ] Old URLs removed from all sitemaps.
• [ ] New sitemaps generated and submitted to GSC.
• [ ] Top 100 old URLs inspected via GSC URL Inspection Tool – all show correct canonical and index status.
• [ ] Full site crawl completed with zero errors on new URLs.
• [ ] Weekly monitoring dashboard set up for indexation rate, impressions, crawl errors.

Using NQZAI for This Playbook

NQZAI accelerates every step of this runbook by automating repetitive verification tasks. For example: - Redirect map validation: NQZAI can ingest your list of old/new URLs, crawl each origin, and output a report of chains, loops, and soft 404s – with actionable fixes. - Canonical alignment: The tool can extract canonicals from all new pages and flag mismatches, then suggest the correct self‑referencing value. - Internal link leak detection: NQZAI can crawl every page, extract all internal links, and compare them against your redirect map, generating a list of pages that still link to old URLs. - Phased monitoring alerts: Instead of manually checking GSC daily, NQZAI can poll the GSC API for Coverage and Performance data, sending alerts when indexation rate drops below 90% or impressions fall below a threshold.

By using NQZAI’s automated workflows, a team can reduce the execution time of this runbook from several days to a few hours, while eliminating human error in cross‑referencing large datasets.

How to Execute a Redirect and Consolidation Indexation Verification – Step‑by‑Step Walkthrough

1. Gather all data sources: Export your redirect map (old URL → new URL), your current XML sitemap, and a crawl of your entire site (using Screaming Frog). Keep these as CSV files.
2. Build a redirect chain validator: Write a simple script (or use NQZAI) that reads the redirect map and crawls each old URL, recording the full chain. Flag any origin with >1 redirect.
3. Crawl the new URLs for canonical compliance: Configure Screaming Frog to crawl the new domain using the new sitemap. Apply a custom extraction for canonical link. Export and filter rows where canonical != current URL.
4. Generate an internal‑link replacement plan: Use Screaming Frog’s “Inlinks” report filtered by the old URL list. For each page linking to an old URL, note the exact anchor and target. Use a database search‑and‑replace tool (e.g., WP‑CLI wp search-replace) to update links. After replacement, re‑crawl and verify zero links to old URLs.
5. Update sitemaps and submit: Delete all old sitemaps from your server. Generate fresh sitemaps using Screaming Frog or your CMS plugin. Submit in GSC. Wait 24 hours, then check the “Sitemaps” report for processing status.
6. Run the targeted validation: For the top 100 old URLs by historical traffic, open each in GSC URL Inspection Tool and note the “Last crawl” date, “Indexing allowed” status, and “Canonical URL”. Any that show issues → fix the cause on the new URL.
7. Set up monitoring: Create a Google Data Studio dashboard connected to GSC (or use NQZAI’s pre‑built one) that tracks indexed count, impressions, clicks, and average position for the new URL set. Schedule a weekly review for 4 weeks. If after 4 weeks indexation <90% or impressions <80% of pre‑consolidation baseline, investigate further (often due to canonical misalignment or site‑wide template changes).

Frequently Asked Questions

How long does indexation take after a redirect?

Google can start crawling the new URL within hours if it is linked from a high‑authority page, but full indexation of all consolidated URLs often takes 2–4 weeks. During that period, use GSC’s URL Inspection Tool to check individual pages – “Indexing requested” means Google has queued it but not yet processed.

Should I use 301 or 302 for temporary consolidation?

Always use 301 (permanent) for content consolidations you do not plan to revert. Google’s documentation states that 301s are treated as explicit permanent moves and pass more ranking signals. A 302 is appropriate only if you may bring the old page back within a few weeks.

What if I need to revert a consolidation?

Reverting is risky because Google may still treat the old URL as canonical after a 301. To revert: remove the 301, restore the old page (with its original content), and set a self‑referencing canonical. Then use the GSC URL Inspection Tool to request re‑indexing of the old URL. Expect a 2–3 week recovery period.

How do I handle pagination consolidation?

If you consolidate multiple paginated pages (e.g., /page/2, /page/3) into a single “view all” page, redirect each paginated page to the consolidated page and set the consolidated page’s canonical to itself. Google’s duplicate‑URL consolidation documentation recommends using rel="prev" and rel="next" indicators on paginated series, but after consolidation those are unnecessary because you are eliminating the paginated pages entirely.

Why are my new URLs showing “Submitted URL not indexed” in GSC Coverage?

This often means Google discovered the URL via sitemap but found a quality issue (thin content, soft 404, or noindex). Re‑crawl the page using Screaming Frog to check for a noindex tag, low word count, or and server‑side redirect back to the old URL. Also check that the page returns HTTP 200 and not a 301 loop.

Can I skip internal link updates if I use a redirect?

No. Internal links are the crawler’s primary discovery path. Even with a perfect 301, Google’s ranking algorithms may not fully transfer the internal link equity to the new URL because they still see the old URL as the authoritative target. Updating internal links directly signals to Google that the new URL is the canonical endpoint.

Sources

1. Google Search Central, Redirects and Google Search – Official guidance on 301/302, redirect chains, and indexability of destination URLs.
2. Google Search Central, Site moves – Documentation on changing site domains, Change of Address tool, and phased migration monitoring.
3. Google Search Central, Consolidate duplicate URLs – Guidance on canonical tags, 301 redirects, sitemap updates, and internal link corrections for duplicate content.
4. Google Search Central, Sitemaps – Best practices for sitemap creation, submission, and removal of old URLs after consolidation.
5. Google Search Central, Index Coverage reports – Interpreting GSC Coverage data to track indexation success.