Site Migration Audit

Phase 1: Pre-launch checks

Before anything goes live, we baseline the current site: top landing pages, index coverage, rankings sample, and backlink landing URLs that must not 404. On staging (or a protected pre-prod), we crawl templates, verify robots and noindex intent, test the redirect map against the old URL inventory, and confirm canonical and hreflang patterns match the future production host. A full pre-launch checklist lives in site migration audit pre-launch checks.

• Inventory of URLs that earn traffic, conversions, or important backlinks
• Redirect map coverage test: every critical old URL has a correct 301 target
• Staging robots / auth / noindex rules that will not ship to production by accident
• Template parity: titles, indexability, structured data, and internal links on new templates
• Sitemap and parameter plan for day-one Search Console submission

# Staging (correct while private)
User-agent: *
Disallow: /

# Production must flip to allow rules + sitemap reference.
# We verify the production robots URL on launch day, not just staging.

Phase 2: Launch-day verification

Launch day is a controlled checklist, not a hope cycle. We sample high-value old URLs for final status codes and hop counts, confirm HTTPS and host normalization, spot-check canonical tags on new templates, and submit updated sitemaps. We watch for soft 404 templates, accidental noindex on money pages, and analytics or Search Console property gaps if the host changed.

1. Freeze redirect map and confirm deploy includes the full batch
2. Hit priority old URLs and record status, final URL, and hop count
3. Verify production robots.txt, XML sitemaps, and canonical host
4. Spot-check new templates for indexability and core content rendering
5. Submit sitemaps and note Inspection samples for critical URLs

Phase 3: Post-launch monitoring

The first two to six weeks show whether Google is accepting the move. We compare coverage and landing-page traffic against the baseline, hunt new 404s from Search Console and crawl, re-check redirect targets that still chain, and flag pages stuck in crawled currently not indexed when the cause looks migration-related. Diagnosis patterns for that status are in crawled currently not indexed diagnosis.

Post-launch is also when hreflang and locale mistakes surface: wrong return tags, mixed hosts, or alternate URLs that still resolve to the retired domain. We sample locale pairs rather than trusting a spreadsheet that was never crawled. If the migration included a design-only template swap with stable URLs, we still re-check render output and internal link modules, because many traffic losses after redesigns come from missing nav paths, not from redirect errors.

Process and timing

We align to your release calendar. Pre-launch work should finish early enough to fix gaps before freeze. Launch support is usually a focused window on cutover day. Post-launch reviews land at agreed checkpoints (for example day 3, day 14, day 30). How we turn findings into sequenced work is covered in turn an SEO audit into a roadmap.

<link rel="canonical" href="https://www.example.com/category/widgets/" />
<!-- Must match the final production host and path strategy.
     Staging hosts and leftover http:// variants are launch blockers. -->

Optional support after the migration window

If residual issues remain, we can extend verification or hand a cleanup backlog to your team. Long-term SEO retainers are out of scope for this product. When you need a wider diagnosis after things settle, compare options on our SEO audit services agency home page, or read SEO audit or ongoing SEO for how a finite audit differs from continuous work.