Post-Migration Audit: Verifying 301 Redirects and Indexation
Traffic drops after a migration are common, but they shouldn't be permanent. Here is the technical protocol to verify that Google has accepted your new site structure.
Analyzing Indexation Latency During Site Migrations
You've set up your 301 redirects. You've updated your sitemaps. You've hit the "Change of Address" button in GSC. Despite valid 301 redirects, traffic volatility often persists due to delays in Googlebot's processing of the new URL structure.
The problem usually lies in the Indexation Gap. This is the period between when you launch the new site and when Google actually swaps the old URLs for the new ones in its index. Just because a redirect works for a user doesn't mean Googlebot has crawled it, understood it, and transferred the ranking signals.
If your old URLs remain indexed while your new URLs sit in the "Discovered - currently not indexed" queue, you are bleeding traffic. The only way to stop this is rigorous, bulk verification.
The 5-Step Post-Migration Audit Protocol
Forget generic advice like "check your robots.txt". You need a data-driven audit process to ensure the handover is complete.
1. Verifying De-indexation of Legacy URLs
Your first goal is to ensure Google is dropping your old URLs from the index. If they persist too long, you risk keyword cannibalization or signal dilution.
- Export a list of your top 1,000 traffic-generating URLs from the old site (via GA4 or GSC).
- Run them through our bulk index checker.
- Goal: You want these to eventually report as "Not Indexed" (or point to the new URL in the SERP).
2. The "New URL" Vitality Check
This is critical. Are your new pages actually live in Google's database? 301 redirects transfer authority, but they don't guarantee instant indexing.
- Export your new XML Sitemap.
- Check the index status of these new URLs.
- If you see a high rate of "Not Indexed", Google is hesitating. This often happens if the content changed significantly during migration.
The Migration Verification Matrix
Understanding which tool to use is about understanding what data layer you are looking at. Do not confuse a "200 OK" status with "Indexed".
| Verification Layer | Primary Tool | What It Confirms | The "Blind Spot" (Risk) |
|---|---|---|---|
| Level 1: Server HTTP Status |
Screaming Frog | Technical connectivity. Confirms redirects (301) are active and chains are broken. | High Risk It confirms the link works, but not if Google has seen it or accepted it. |
| Level 2: Database Google Index |
GSC (Owned) | Google's intent to index. Shows "Crawled" or "Discovered" status. | Medium Risk Data is delayed by 3-5 days. Useless for real-time migration monitoring. |
| Level 3: Live SERP Public Visibility |
SpeedyIndex | Reality check. Confirms the new URL is actually served to users in search results. | Low Risk Only checks provided URLs (requires a clean sitemap export). |
Pro Audit Tip: For large-scale migrations, don't rely on samples. Perform a bulk verify site migration indexation to get a real-time JSON-formatted overview of your new URL structure's visibility.
Diagnosing Traffic Drops After Migration
If your audit reveals that new pages aren't indexing, you need to troubleshoot the root cause immediately.
Scenario A: The "Page with Redirect" Loop
Sometimes GSC reports Page with redirect errors incorrectly, or Google refuses to follow the redirect because the new page content is too different. Ensure your 301s are direct (A -> B), not chains (A -> B -> C), and that the thematic relevance is preserved.
Scenario B: The Soft 404 Trap
If you redirected a bunch of old product pages to a generic category page because the products were discontinued, Google might treat these as Soft 404 errors. This kills the link equity. Always redirect to the most specific equivalent possible.
Scenario C: Server Errors
Migrations put a heavy load on servers as bots recrawl everything at once. Where indexing submissions also need to be distributed, you can stage indexing submissions across multiple days. Monitor your logs for 5xx errors. If Googlebot repeatedly encounters 503 responses, it may reduce its crawl rate and delay recovery.
Pro Tip: Don't just wait. If your critical new landing pages aren't indexing after 48 hours, use our Indexing Service to force Googlebot to re-crawl them. This is the fastest way to push a migration through.
Frequently Asked Questions (Migration Survival Guide)
How long does it take for traffic to recover after a site migration?
For a well-executed migration, volatility typically lasts 2-4 weeks. If traffic hasn't stabilized after 6 weeks, it indicates a technical failure (e.g., broken redirect chains, orphaned pages, or crawl budget issues) requiring an immediate audit.
Why is my new site not indexing after migration?
The most common reasons are: 1. Google hasn't crawled the new URLs yet (low crawl budget). 2. The old site is still indexed (signals haven't transferred). 3. Quality issues. Use a bulk index checker to confirm status, then use an indexing service to force a re-crawl.
Should I use the Google Change of Address tool?
Yes, but only if you are changing domains (e.g., brand.com to newbrand.com). It sends a strong signal to Google to prioritize the swap. Do NOT use this tool for simple protocol changes (HTTP to HTTPS) or URL structure changes on the same domain.
How long should I keep 301 redirects active?
Permanently, or for at least 12 months. Google recommends keeping 301 redirects in place indefinitely to ensure all link equity passes to the new domain and to capture users clicking on historical backlinks from external sites.
What is the difference between 301 and 302 redirects?
Always use a 301 (Permanent) redirect for migrations. A 301 tells Google to transfer ranking history and authority to the new URL. A 302 (Temporary) redirect tells Google to keep the old URL in the index, which will disastrously fail a migration.
Why are redirect chains bad for SEO?
A redirect chain (Page A > Page B > Page C) causes latency for users and wastes Crawl Budget for bots. Googlebot may stop following the chain after 5 hops, meaning the final destination page never gets indexed or credited with the link equity.
Should I delete my old sitemap after migration?
No. Keep the old sitemap active in GSC for at least 3-6 months. This forces Googlebot to revisit the old URLs, encounter the 301 redirects, and update its index faster. Only remove it once the old URLs have completely dropped out of the SERP.