Step-by-Step SEO Site Migration Checklist for Smooth Transitions
SEO migration in 2025 operates under completely different rules than just a few years ago.
Google’s AI overviews now intercept traffic before users reach your pages. INP replaced FID as a Core Web Vitals metric. Entity recognition affects how search engines understand content relationships during architectural changes. Modern React and headless CMS migrations require different technical considerations than traditional platform swaps.
These changes mean migration strategies need updating. What worked for simple WordPress moves won’t handle the complexity of modern site architectures and search engine behaviors.
Hi there! I’m Roman Makarenko, founder of Thunder Marketing Solutions. My path through digital marketing started eight years ago, and crossing the $1 million mark on Upwork taught me that successful migrations separate professionals from pretenders.
In this guide, I want to tell you about the technical realities of migrating sites when search engines use entity recognition, AI summaries, and mobile-first indexing to evaluate your content. Every checkpoint reflects what actually matters for preserving and improving organic performance during major site changes.
I’ll start with some foundational concepts — if you’re already familiar with migration basics, feel free to jump straight to the first step.
Before we start — are you dealing with a migration right now, or still in the “thinking about it” phase? Either way, drop a comment about what’s driving the change and I’ll share which parts of this guide to focus on first.
What is an SEO Site Migration?
An SEO site migration is any change that materially alters your URLs, site architecture, design, tech stack, domain, or content in ways that can affect your organic search visibility.
Think domain changes, CMS platform swaps, HTTPS implementation, subdomain to subfolder moves, JavaScript framework rebuilds, or major information architecture overhauls. When Google needs to relearn how to crawl, index, or rank your site, you’re dealing with a migration.
Even changes that seem minor can create major problems. Last year, a client changed their URL structure from /services/web-design/ to /web-design-services/ without setting up redirects. They thought it was cleaner. Google thought 200+ pages had disappeared. Traffic dropped 40% before we caught the issue.
Why Should You Consider a Site Migration?
Smart migrations unlock performance, user experience, brand, or technical gains that outweigh short-term ranking volatility.
Your current CMS might limit the content strategy you need to compete. Site speed could be destroying conversions. You’re rebranding and need a new domain. Or your information architecture no longer matches how customers search for your services.
At Thunder Marketing Solutions, we only recommend migrations when business benefits clearly justify SEO risks. Chasing the latest platform because it sounds cooler? Skip it. Moving because your current setup blocks growth? Different story.
How Long Does a Site Migration Take to Complete?
⏳Planning and build: 4–12+ weeks depending on scope and complexity.
⏳Stabilization: Expect ranking and traffic fluctuations for several weeks after launch. Google recommends keeping redirects active for at least 180 days. I keep them running for 12 months to be safe.
Perfect stability after migration doesn’t exist. Search engines need 2–6 weeks to reprocess your new setup. Domain moves take longer to stabilize than platform changes that preserve URLs.
For domain changes, keep your old domain paid and secured for at least a year. I’ve seen competitors buy expired domains and redirect them to their own sites.
What Types of Site Migrations Should You Know About?
Not all site migrations carry the same risk. Some changes barely register with search engines, while others can tank your rankings if mishandled. I’ve categorized these migrations by their complexity and potential impact. Let’s see.
Low-Risk Migrations
No-URL moves like hosting changes, CDN implementations, or server stack updates typically cause minimal disruption. Your URLs stay identical, so Google doesn’t need to relearn your site structure.
Watch for temporary downtime and make sure all technical configurations transfer correctly.
Protocol changes from HTTP to HTTPS fall here, too, though they need careful redirect planning. Google treats HTTPS as a ranking signal, so this migration often improves performance once stabilized.
Medium-Risk Migrations
Platform or CMS changes hit the sweet spot of migration complexity. Moving from WordPress to a headless CMS or switching e-commerce platforms requires careful URL preservation and template mapping. Rankings usually recover within 4–6 weeks when handled properly.
Subdomain to subfolder moves (or vice versa) create moderate volatility. Search engines treat subdomains and subfolders differently for authority distribution, so expect some ranking fluctuations during transition.
High-Risk Migrations
Domain changes top the risk chart. Every URL changes, requiring extensive redirect mapping and Google’s Change of Address tool. Even perfect execution typically results in 2–3 months of ranking instability as search engines rebuild their understanding of your site’s authority.
Path and information architecture changes alter how your content gets organized and accessed. Changing from /services/web-design/ to /web-design/ across hundreds of pages creates substantial redirect complexity.
Maximum-Risk Migrations
Hybrid migrations combine multiple changes simultaneously — new domain, redesigned information architecture, and platform switch. These create the perfect storm of SEO disruption.
A SaaS client wanted to rebrand, restructure their entire site architecture, and switch from WordPress to a custom React framework. All at once. We convinced them to phase the changes over six months instead of doing everything simultaneously. Smart move — their organic traffic actually grew during the process instead of cratering.
So, my golden rule: limit changes to one category when possible. Change domains but preserve your existing URL structure. Redesign information architecture, but keep your current domain. The more variables you change simultaneously, the harder it becomes to diagnose and fix problems when they pop up.
I’ve broken down the rest of this guide into logical steps that follow the natural migration sequence. So, how about we already walk through them?
Step 1: What to Plan Before Starting Your Site Migration
Success starts before you touch a single line of code. Skip this phase and you’ll spend months fixing problems that proper planning prevents.
Start with a complete site audit. Document everything about your current setup — not just traffic numbers, but the full technical picture. Run crawls using Screaming Frog or Sitebulb to map every indexed URL.
Capture baseline analytics data, including traffic patterns, conversion paths, and bounce rates by page. Screenshot key page layouts for reference when questions arise later.
Your migration needs clear objectives. Are you fixing technical debt? Improving user experience? Supporting new business requirements? Document these priorities because trade-offs will emerge, and you’ll need criteria for making decisions under pressure.
Staging Environment Setup
Your staging environment must mirror production exactly, the same server configuration, same database structure, same third-party integrations. Half the migration disasters I’ve debugged traced back to staging environments that didn’t match production realities.
Staging Environment Setup
Your staging environment must mirror production exactly, the same server configuration, same database structure, same third-party integrations. Half the migration disasters I’ve debugged traced back to staging environments that didn’t match production realities.
✍️Essential staging checklist:
- Authentication: HTTP auth or IP allowlist enabled to block public access
- Noindex tags: Meta robots noindex on all pages as indexing protection
- Robots.txt: Disallow directive is active to prevent search engine crawling
- Analytics off: Route tracking to test properties or disable completely
- Payments sandbox: All payment systems in test mode only
This covers the critical elements that prevent staging sites from interfering with production SEO. However, you can see the full staging matrix in Appendix A for the complete verification checklist.
Timeline and Resource Planning
Build buffer time into every milestone. Even simple migrations encounter unexpected complications — third-party integrations that break, redirect rules that conflict with server configurations, or content management workflows that don’t transfer cleanly.
- Planning and build phase: 4–12+ weeks, depending on complexity
- Testing and refinement: 2–4 weeks minimum
- Launch coordination: 1 week for final preparations
Assign specific responsibilities to team members. Migration projects fail when everyone assumes someone else is handling critical tasks. Document who owns redirect mapping, who verifies tracking implementation, and who monitors post-launch performance.
Content and Asset Preparation
Freeze content changes during the final two weeks before migration. New blog posts, updated service pages, or modified product descriptions create moving targets that complicate testing and increase error chances.
Audit your media library. Broken image links and missing downloads create poor user experiences that damage conversion rates. Clean up unused files while preserving anything linked from external sources.
Create rollback plans for each migration component. Domain changes, redirect implementations, and DNS modifications should all have documented reversal procedures. You probably won’t need them, but having clear rollback steps reduces decision-making pressure during crisis situations.
Step 2: Reviewing Content and Keywords for Your Site Migration
Before changing a single URL, verify which keywords actually drive business value. Migration planning fails when teams focus on preserving every ranking instead of protecting what matters most.
Start with your highest-converting keywords and pages. Pull analytics data showing which search terms drive qualified traffic, not just volume. A keyword ranking #3 with 200 monthly searches might generate more revenue than your #1 ranking term with 2,000 searches if the intent alignment is better.
Verify your site’s current content performance before restructuring. Identify pages that consistently convert visitors, content that earns backlinks naturally, and resources that users share most frequently. This baseline helps you prioritize which content relationships must be preserved during migration.
Map your content to search intent and user journeys. Information architecture changes often break the logical flow from search query to relevant content.
When restructuring your site, maintain clear paths between what people search for and where they land. A migration that preserves rankings but destroys user experience will damage conversion rates even if traffic stays stable.
AI-Era Considerations
Search behavior is shifting as AI features become more prominent in search results. Your content strategy needs to account for how AI overviews and enhanced snippets affect visibility.
Entity mapping becomes more important than exact keyword matching. Google’s algorithms now understand topical relationships and semantic connections between concepts.
When planning URL changes, consider how entity associations might be affected. Your “project management software” content shouldn’t get separated from related “team collaboration” and “workflow automation” content during restructuring.
📝Content evaluation for AI features:
- E-E-A-T signals: Experience, expertise, authoritativeness, and trustworthiness matter more than keyword density
- People-first content: AI systems favor content that serves user needs over search engine optimization tricks
- Structured data compliance: Clean, accurate schema markup helps AI systems understand and reference your content
- FAQ and how-to reality: Rich snippets for FAQ content are limited to high-authority sites; don’t build migration expectations around capturing these features
Review your content through a pruning lens. Pages receiving minimal organic traffic often create more SEO problems than they solve. Thin content dilutes your site’s overall relevance signals. During migration, consider consolidating similar pages or implementing strategic redirects instead of preserving every existing URL.
Content Architecture Decisions
Document which content deserves individual pages versus what should be consolidated.
Two separate pages targeting “email marketing tips” and “email marketing best practices” might serve users better as one strong resource, especially post-migration, when you need search engines to identify clear topical authority.
Test your content against user search patterns, not just keyword research tools. Voice search and conversational queries are changing how people find information. Content that answers natural language questions often performs better than pages optimized for traditional keyword phrases.
Plan for content gaps that migration might create. When changing information architecture, some content relationships become less obvious to both users and search engines. Build internal linking strategies that maintain topical connections even when URL structures change.
Sitting on a pile of content that barely gets traffic and wondering whether to migrate it all? Describe your content situation in the comments. The pruning decisions get easier with an outside perspective.
Step 3: Creating a Clear URL Architecture and Redirect Plan
Your redirect strategy determines whether migration preserves or destroys your search equity. The goal is simple: minimize URL changes, and when changes are necessary, keep them predictable with single-hop redirects.
Create a comprehensive redirect map documenting every URL change. Your spreadsheet should include the original URL, target destination, redirect type, reasoning, and canonical URL if different from the target. Don’t take shortcuts here — incomplete redirect mapping is the fastest way to crater your organic traffic.
Use permanent redirects (301 or 308) for permanent moves. Google recognizes 308 as permanent just like 301, though 301 remains more widely supported.
Avoid redirect chains at all costs. When URL A redirects to URL B, which redirects to URL C, search engines may not follow the full chain, and page load speeds suffer.
Technical Implementation
Basic 301 redirect in .htaccess:
︳RewriteRule ^old-page/?$ /new-page [R=301,L]
Check for redirect chains:
︳curl -I -L http://example.com/old-url
Batch redirect validation:
︳for url in $(cat urls.txt); do curl -I -s $url | head -1; done
Handle removed content properly. Use 410 status codes for pages that are permanently gone and shouldn’t be redirected anywhere. Don’t blanket-redirect irrelevant pages to your homepage — this creates soft 404s that confuse search engines.
URL Structure Decisions
Establish consistent rules for parameters, trailing slashes, and case sensitivity. Your site should canonicalize to one version: either /page/ or /page, never both. The same principle applies to capitalization — choose lowercase URLs and stick with it throughout your site architecture.
For faceted navigation and parameter-heavy pages, decide what gets indexed versus what gets canonicalized. E-commerce sites often need crawlable category pages, but should canonicalize or noindex filtered views like /category?color=red&size=large.
I leave a full redirect QA pack in Appendix B, which contains comprehensive testing procedures, but these core checks catch most implementation errors before they impact search performance.
Step 4: Technical SEO Checklist for Your Site Migration
Technical details determine whether your migration succeeds or quietly fails months later. These checkpoints catch the problems that destroy organic traffic while everyone’s celebrating launch day.
1. Sitemaps
Ship clean XML sitemaps with accurate lastmod dates. Google killed the ping endpoint, so you need to submit through Search Console manually now. No shortcuts here.
Structure your sitemaps like a filing cabinet — use a sitemap index that points to category-specific files instead of dumping 50,000 URLs into one massive document. Every URL in your sitemap should return a clean 200 status. I’ve debugged migrations where teams included thousands of 404ing URLs in their sitemaps, confusing search engines for weeks.
2. Dynamic Rendering
Dynamic rendering means showing different content to search engines than what users see. Google calls this a “workaround” and discourages it long-term.
If your JavaScript-heavy site needs dynamic rendering during migration, document it as temporary and plan your exit strategy.
Move toward server-side rendering, incremental static regeneration, or proper hydration as soon as possible. The gap between bot and user experiences creates maintenance nightmares and ranking volatility.
3. Mobile-First Reality
Google crawls your mobile version first. Your mobile site needs the same content, structured data, and internal links as the desktop. Test everything using Googlebot-smartphone user agent — this shows exactly what search engines actually see.
Mobile parity doesn’t mean identical layouts. Accordion content, simplified navigation, and optimized images work fine as long as users can access the same information and complete the same actions. The functionality matters more than visual similarity.
4. Core Web Vitals Budget
Set performance budgets for LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), and INP (Interaction to Next Paint).
INP replaced First Input Delay in 2024 and measures responsiveness throughout the entire page lifecycle, not just initial interactions.
Test with lab tools like Lighthouse for debugging, but field data from Chrome UX Report determines rankings. Sites often pass lab tests but fail real-world measurements because users have slower networks and older devices than your testing environment assumes.
5. Site Name and Favicon Updates
Update these correctly for domain or brand changes. They appear in search results and browser tabs — first impressions matter. Submit your preferred site name through Search Console’s site settings instead of hoping Google picks the right one automatically.
6. Spam Policy Traps
Avoid doorway page patterns when restructuring URLs. Don’t let third-party content hitchhike on your domain post-migration.
Guest posts, affiliate content, and syndicated material that doesn’t serve your users directly can trigger site reputation abuse penalties.
Clean house during migration. Review any content that might violate Google’s spam policies before it transfers to your new setup.
7. IndexNow Integration
Submit important URLs to IndexNow for faster discovery on Bing and other supporting engines. These supplements don’t replace Google’s crawling process.
Implementation takes minimal effort and accelerates indexing across multiple platforms simultaneously.
Step 5: On-page SEO and Structured Data QA Checklist
On-page elements often break silently during site migration. Your SEO migration success depends on catching these issues before they damage search performance.
Start with automated comparisons between old and new pages. Run diff tools that flag changes in title tags, meta descriptions, H1-H6 structures, word count, and internal link patterns. Manual spot-checking misses too many problems when you’re dealing with hundreds or thousands of pages.
📊Essential automated checks:
- Title tag preservation and keyword inclusion
- Meta description transfer and call-to-action language
- Heading hierarchy maintenance (especially H1 uniqueness)
- Content length and key section preservation
- Internal link structure and anchor text consistency
Content Parity Verification
Your new pages need the same content depth as the originals. This goes beyond word count — verify that key trust signals, testimonials, contact information, and calls-to-action transfer correctly.
Missing elements that seem minor can destroy conversion rates even when search rankings stay stable.
Check image optimization during migration. Ensure alt text transfers properly, file names remain descriptive, and responsive image serving works across devices. Images without proper alt text waste crawl budget and miss accessibility requirements.
Canonical and Technical Elements
Verify self-referencing canonicals point to the correct URLs — not the old domain or staging environment.
I’ve debugged migrations where canonical tags continued pointing to development servers weeks after launch.
Test your custom 404 page thoroughly. It should maintain brand consistency, include helpful navigation options, and offer search functionality. A broken 404 page creates poor user experiences that hurt engagement metrics.
Schema Markup Validation
Run structured data through Google’s Rich Results Test tool and Schema.org validator. Clean, accurate markup helps AI systems understand your content, but don’t build migration expectations around capturing rich snippets.
Google limits FAQ rich results to high-authority sites, so focus on markup that serves users rather than chasing SERP features.
Update breadcrumb, Article, and Organization schema to reflect new URL structures and brand changes. Schema errors can prevent rich results from displaying and confuse search engines about your site’s structure.
Your site migration checklist should include spot-checking critical page templates after schema updates. Verify that product pages, blog posts, and service pages maintain consistent structured data patterns across the new architecture.
Step 6: Verifying Analytics, Tags, and Tracking Before Migration
Your analytics setup can make or break post-migration analysis. Lose tracking data during your SEO migration, and you’ll spend months guessing whether traffic changes came from the migration or seasonal patterns.
GA4 requires different planning than Universal Analytics used to. Preserve your Measurement ID, custom events, and conversion definitions exactly. Domain migrations need cross-domain tracking configured properly — otherwise, Google treats your new domain like a referral source instead of the same business. Set up server-side Google Tag Manager if you’re using it, and test thoroughly in staging before going live.
Create separate GA4 properties for before and after comparison if you’re changing domains significantly. This gives you clean data sets without the messy attribution problems that happen when one property tracks completely different domains over time.
KPIs shift with GA4 migration:
- Monitor engagement rate instead of bounce rate
- Track assisted conversions alongside direct conversions
- Watch source/medium attribution by page template
- Verify that enhanced e-commerce events transfer correctly
Set up both old and new Search Console properties and link them to GA4. For domain changes, you’ll need the old property to track how redirects perform and the new one to monitor indexing progress. Keep both active until traffic fully stabilizes on the new domain.
BigQuery export becomes valuable during site migration if you have access. Raw data lets you reconstruct analytics even when standard reports get muddied by attribution changes. Export your historical data before migration begins — you’ll thank yourself (and me) later when stakeholders ask for year-over-year comparisons that span the migration date.
So, your SEO site migration checklist needs to include verification of every tracking pixel, conversion tag, and measurement script. E-commerce tracking breaks easily during platform changes. Subscription forms lose conversion tracking. Even simple contact form submissions can stop reporting properly if JavaScript placement changes.
Test everything twice: once in staging with fake transactions, then again on production with small real transactions. Analytics problems reveal themselves gradually, not immediately after launch.
Juggling multiple analytics platforms during migration and feeling overwhelmed? Describe your current tracking setup — sometimes simplification is the real solution.
Step 7: Creating a Go-live Runbook for SEO Site Migration
Launch day separates successful SEO migrations from disasters. Your runbook needs to be foolproof because adrenaline and time pressure make smart people do stupid things.
Lower DNS TTL values 48–72 hours before cutover. This speeds up propagation when you flip the switch. Run final crawls of your old site to capture any last-minute content changes that might have slipped through your content freeze. Verify redirects work in staging with production-like server configurations — staging environments that don’t match production cause nasty surprises during launch.
Remove noindex tags from your new site and double-check robots.txt files. Teams frequently forget these blocking mechanisms, leaving new sites invisible to search engines for days or weeks after migration.
Test your top page templates one final time, including forms, checkout processes, and contact mechanisms.
Hour-by-Hour Launch Sequence
- T-2 hours: Final backup verification and team communication check
- T-1 hour: Enable redirects, push updated sitemaps to Search Console
- T-0: DNS cutover, verify server response codes across key templates
- T+30 min: Test critical user flows, confirm tracking fires properly
- T+1 hour: Run URL Inspection on priority pages, monitor server logs
- T+2 hours: Check redirect chains, validate canonical tags point correctly
- T+4 hours: Verify analytics data flows, test conversion tracking
- T+8 hours: Monitor crawl errors, confirm sitemap submission worked
I leave the full T-7 → T+14 timeline with detailed verification steps for you in Appendix C; you can see it at the end of the article.
Team Coordination
Assign specific people to monitor different systems during launch. One person watches server performance, another monitors analytics, and someone else handles redirect verification. Confusion kills momentum when problems surface and everyone needs to act quickly.
Create a shared communication channel for launch day only. Email chains get messy when multiple issues arise simultaneously. Set clear escalation paths so junior team members know exactly who to contact when specific problems occur.
Your site migration checklist should include customer communication plans. Some users will notice changes immediately, especially for e-commerce sites or member areas. Prepare support teams with answers about new features, moved content, or temporary issues they might encounter.
Document everything that goes wrong, even small issues. These notes become invaluable for your next SEO site migration project and help teams avoid repeating the same mistakes.
Step 8: Post-migration Monitoring and Issue Resolution
Launch day is just the beginning. Real SEO migration success gets measured in the weeks that follow when search engines reprocess your site and traffic patterns stabilize.
Search Console Monitoring
Watch coverage reports like a hawk. New indexing errors often surface 24–48 hours after launch as Google discovers your redirect patterns.
Submit priority URLs through URL Inspection for faster recrawling — don’t wait for natural discovery when you need search engines to understand your changes quickly.
Manual actions notifications require immediate attention. Site migrations can trigger algorithmic reviews, especially when multiple signals change simultaneously. Check enhancement reports for structured data errors that might have emerged during the technical transition.
Server Logs Analysis
Monitor Googlebot-smartphone activity levels and response codes. Traffic spikes to your redirect rules indicate search engines are processing the changes properly. Watch for 404 spikes on URLs that should be redirecting — these reveal gaps in your redirect mapping.
Redirect chains show up clearly in server logs. A single 301 followed by another 301 creates performance problems and dilutes link equity transfer. Fix these immediately rather than letting them accumulate.
Dashboard Tracking
Your site migration needs continuous performance monitoring, not just launch-day verification. Rankings fluctuate normally for 2–6 weeks as search engines reindex your content with new signals.
As previously, you can see the full dashboard spec in Appendix D for complete tracking configurations and alert thresholds.
Core Web Vitals field data updates slowly — lab measurements change immediately, but ranking signals depend on real user experiences accumulated over weeks. Remember, don’t panic over temporary performance dips during the adjustment period, it’s absolutely normal.
Keep redirects active longer than Google’s 180-day minimum recommendation. Traffic might still hit old URLs from bookmarks, external links, or cached search results months after your site migration. Monitor redirect traffic volume to determine when removal makes sense.
Step 9: How to Handle International SEO During Migration
International sites face unique challenges during SEO migration. Hreflang implementation gets messy fast when URLs change, and mistakes can tank your rankings in specific regions for months.
Update every hreflang pair to point to new URLs. This sounds obvious, but teams frequently miss reciprocal links between language versions. Your English page needs to reference the French version, and the French page must reference the English version back. Break this reciprocity, and search engines ignore your hreflang signals entirely.
Domain changes create the biggest hreflang nightmares. Avoid cross-domain hreflang implementations where some languages live on the old domain while others move to the new one. This confuses search engines about your site architecture and dilutes regional authority signals.
🗺️Regional content verification checklist:
- Canonical tags point to correct regional versions, not global defaults
- Currency, contact information, and legal disclaimers match local requirements
- Regional contact forms route to appropriate local teams
- Local business schema reflects accurate address and phone data
Don’t rely on IP-based redirects for regional content during your site migration. These breaks are for VPN users, international travelers, and search engine crawlers that may access your site from different geographic locations. Use clear URL structures with proper hreflang markup instead.
Content parity between regions needs careful attention. Your German site shouldn’t lose product descriptions or contact information that existed before migration. Regional SEO rankings depend on maintaining equivalent content depth and user experience across all language versions, not just preserving the primary language content.
Time to Build Something Better
Site migrations taught me patience. Every shortcut I tried early in my career came back to bite me during the most stressful moments. Now at Thunder Marketing Solutions, we treat migrations like surgery — methodical preparation, steady execution, careful monitoring.
The checklist above represents years of fixing problems that could have been prevented. Broken redirects discovered weeks after launch. Analytics gaps that made performance analysis impossible. Technical configurations that worked perfectly in staging but failed in production. It’s hard to remember all this.
What strikes me most about successful migrations is how boring they should feel. No drama during launch day. No emergency fixes needed at midnight. No traffic cliffs that require months of recovery work. When you follow systematic processes, migrations become routine business improvements rather than gambling with your organic visibility.
The stakes are real, but so are the rewards. Your business deserves a migration that strengthens rather than threatens your search presence. Take the time to plan properly, execute carefully, and monitor thoroughly.
I hope this guide helps you avoid the expensive mistakes that taught me these lessons. Good luck with your migration!
Still have migration questions that this guide didn’t cover? Drop them in the comments below. I read every single one and try to share insights that might help your specific situation.
Appendices
Appendix A — Staging Check Matrix
Appendix B — Redirect QA Query Pack (regex & CLI)
1) Common regex patterns (mapping & hygiene)
- Remove default index files → folder root
⎸/(index\.html?|index\.php|default\.aspx?)$ → /
- Force trailing slash (folders) — (or the reverse rule if your canonicals are no-slash)
⎸^(.+[^/])$ → $1/
- Lowercase enforcement (detect uppercase URLs)
⎸[A-Z] (flag any URL containing uppercase letters)
- Drop marketing params
⎸[\?&](utm_[^=&]+|gclid|fbclid)=[^&]+ (strip or canonicalize)
- Old to new path example
⎸^/blog/([a-z0–9-]+)/?$ → /insights/$1/
2) CLI quick checks (paste into Terminal)
- Check a single URL header chain
⎸curl -I https://oldsite.com/old-page
- Follow and report final URL + status + redirects count
⎸curl -s -I -L https://oldsite.com/old-page -o /dev/null -w “%{url_effective} %{http_code} %{num_redirects}\n”
- Bulk-test a list of old URLs (urls.txt)
⎸xargs -n1 -I{} sh -c ‘printf “{} -> “; curl -s -I -L {} -o /dev/null -w “%{url_effective} %{http_code} %{num_redirects}\n”’ < urls.txt
- Find non-200 final responses
⎸xargs -n1 -I{} sh -c ‘curl -s -I -L {} -o /dev/null -w “%{http_code}\n”’ < urls.txt | grep -v ‘²⁰⁰$’
- Detect redirect chains >1 hop
⎸xargs -n1 -I{} sh -c ‘curl -s -I -L {} -o /dev/null -w “%{num_redirects} %{url_effective}\n”’ < urls.txt | awk ‘$1>1’
3) Log-level queries (adapt field names)
- Top 404s after launch (BigQuery-style pseudo-SQL)
SELECT
request_url, COUNT(*) AS hits
FROM logs.requests
WHERE status = 404 AND timestamp BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 3 DAY) AND CURRENT_TIMESTAMP()
GROUP BY request_url
ORDER BY hits DESC
LIMIT 200;
- Redirect chains (3xx → 3xx within 10s window)
SELECT a.request_url AS from_url, b.request_url AS to_url, COUNT(*) chains
FROM logs.requests a
JOIN logs.requests b
ON a.client_ip=b.client_ip
AND a.user_agent=b.user_agent
AND a.timestamp < b.timestamp
AND TIMESTAMP_DIFF(b.timestamp, a.timestamp, SECOND) BETWEEN 0 AND 10
WHERE a.status BETWEEN 300 AND 399
AND b.status BETWEEN 300 AND 399
GROUP BY from_url, to_url
ORDER BY chains DESC
LIMIT 200;
Appendix C — Sample Cutover Timeline (T-7 → T+14)
Appendix D — Monitoring Dashboard Spec (GSC, GA4, CWV, Logs)
