How to Scan Your Website After a Migration

Website migrations are where broken links are born in bulk. You spend weeks planning the move, mapping old URLs to new ones, testing on staging. Then you go live and discover the 47 things you forgot to account for.

This isn't a failure of preparation - it's the nature of migrations. Every CMS, hosting environment, and domain configuration has its own quirks. The redirect map covers the pages you knew about. What breaks is everything else.

What breaks in a migration

Internal links pointing to old URLs

You set up 301 redirects from old paths to new ones. Good. But internal links in your content still point to the old URLs. Users follow the redirects fine, but you're serving redirect chains on your own site - your own pages routing through redirects to reach your own content. Search engines see this too.

After migration, internal links need to be updated to point directly to new URLs. Redirects are for external links you can't control - not for your own site's navigation.

Assets that didn't transfer

Uploaded files - images, PDFs, attachments - are often stored outside the main codebase and not always included in migration checklists. An image uploaded to /wp-content/uploads/2020/ may not exist in the new environment if the media library wasn't migrated completely.

Hardcoded absolute URLs

Content that contains absolute URLs (not relative paths) to the old domain keeps pointing there after the domain changes. A blog post that links to https://old-domain.com/contact instead of /contact is now an external link to a domain you no longer control.

Subdomain changes

Moving from www.example.com to example.com or vice versa, or changing blog.example.com to example.com/blog - these are URL changes on every affected page and require their own redirect handling.

Environment-specific configuration

SSL certificates, HTTPS enforcing, www/non-www canonicalization, trailing slash handling - these differ between hosting environments. Something that "just worked" on the old host may behave differently on the new one.

The pre-launch scan vs the post-launch scan

Ideally you run a scan before going live - against your staging environment - to catch the obvious issues before users see them. But staging environments often don't perfectly mirror production: different hostnames, different CDN configs, different SSL certificates. Things that pass on staging break on production.

Run a scan immediately after going live, before you announce the migration widely. The window between "live" and "announced" is your best opportunity to catch issues while traffic is still low.

Migration checklist - what to scan for

• -All 404s - any page that returned 200 before migration should still return 200 (or 301 to a valid destination). A 404 that didn't exist before is a migration bug.
• -Redirect chains - internal links pointing to URLs that redirect, especially multi-hop chains created by layering the new migration redirects on top of old ones.
• -SSL errors - new hosting environment, new certificate. Confirm HTTPS works across the full domain including subdomains.
• -Mixed content - hardcoded HTTP references to assets now on an HTTPS domain.
• -Missing assets - images, PDFs, and files that weren't included in the migration scope.
• -Canonical tags - confirm they point to the new domain, not the old one.

Scanning the old domain too

After migration, the old domain should either redirect all traffic to the new domain or be taken down. If it's still serving content independently, you have a duplicate content problem. If it's redirecting, verify the redirects are working and aren't causing chains. A scan of the old domain reveals whether it's behaving as expected.