Appendix D: Migration Protocol

Appendix D provides a step-by-step protocol for site migrations, redesigns, and URL changes. It covers pre-migration planning (audit existing links, map redirects), during-migration execution (301 redirects, updating internal links), post-migration verification (crawl for errors, monitor traffic), and stabilization (confirm recovery, update matrix). Following this protocol minimizes the loss of internal link equity during structural changes.

Migration planning is critical because poor migrations are the #1 cause of internal link equity loss. Without proper planning, you can lose 10-30% of your authority during a migration. Redirect chains, broken links, and orphan pages are common migration errors. Proper planning prevents these losses and ensures a smooth transition.

The four phases are: Pre-Migration (2 weeks before), During Migration (execution), Post-Migration (48 hours after), and Stabilization (1 month after). Each phase has specific tasks to ensure your internal linking structure survives the migration. Following all phases prevents authority loss.

Two weeks before a migration, you should: run a full site crawl with Screaming Frog and export all internal links, create a 301 redirect inventory mapping every old URL to its new URL, identify priority pages (those with the most internal links), document anchor text used for links to PVNs, and create a linking matrix backup. This creates your baseline.

Map every old URL to its new URL. Include all PVNs in your redirect map. Document anchor text used for links to PVNs. Use a spreadsheet with columns: Old URL, New URL, Redirect Type (301), and Notes. This ensures you don't miss any important URLs during the migration.

Priority pages are pages with the most internal links. These should be your top priorities for preservation during the migration. Use Screaming Frog to find pages with the highest "In Links" count. These pages pass the most authority. Ensure their links are preserved.

Anchor text should be preserved during migrations. When URLs change, the anchor text should remain the same to maintain relevance signals. Documenting anchor text ensures you don't lose the semantic value of your links. This is especially important for PVNs.

A linking matrix backup is an export of your current linking matrix before the migration. This is your baseline for post-migration comparison. It helps you verify that all links were preserved and that authority flow remains intact. Without a baseline, you can't measure migration success.

During migration execution, you should: implement 301 redirects one by one (test each before going live), update internal links directly to point to new URLs (don't rely on redirects), verify menus and navigation include direct links to PVNs, and update contextual links within content. This preserves authority flow.

Redirects consume link equity (estimated 10-15% loss per hop). Updating internal links directly to the new URL avoids this loss. Redirects should be used for external links and old bookmarks, not for internal navigation. Direct updates preserve 100% of link equity.

"One by one" means implementing 301 redirects individually and testing each before going live. Don't mass-redirect without verification. Each redirect should be tested to ensure it works correctly. This prevents redirect chains and broken links.

Testing each redirect ensures it works correctly and points to the right destination. A single broken redirect can waste authority and frustrate users. Testing before going live prevents these issues. It's better to find problems during testing than after launch.

48 hours after a migration, you should: run a full site crawl with Screaming Frog to check for internal links pointing to old URLs without redirects (404 errors), inspect 10-15 PVNs in Search Console (URL Inspection) and request indexing if needed, and monitor PVN traffic closely for drops. This catches issues early.

The post-migration crawl is running Screaming Frog immediately after the migration to check for errors. It reveals broken links, redirect chains, and orphan pages. This is essential because migrations often introduce issues that weren't present before. The crawl catches them so you can fix them quickly.

Look for: internal links pointing to old URLs without redirects (404 errors), redirect chains (A→B→C), orphan pages (pages with zero internal links), and PVNs that are no longer reachable. These are the most common migration errors. Fix them immediately.

Use URL Inspection to check 10-15 PVNs. If they haven't been crawled, request indexing. Also, monitor the "Coverage" report for new errors. Search Console shows you what Google sees. If Search Console shows errors, fix them quickly.

A drop of 10-15% for 2-4 weeks is normal as Google re-indexes your site. A drop of more than 20% suggests link equity loss. If traffic drops more than 20%, investigate redirects and internal links immediately. Most drops recover within 4-6 weeks.

Investigate immediately. Check redirects — are they all working? Check internal links — do they point to the right URLs? Check PVNs — are they still receiving links? Check Search Console — are there new errors? Fix what you find. Most issues can be resolved quickly.

One month after a migration, you should: compare the number of indexed pages before and after (Search Console > Index > Pages), rebuild your linking matrix with new URLs, recalculate click depth for PVNs, update your architecture diagrams, and document the migration for future reference.

Comparing indexed pages tells you if Google has re-indexed your site correctly. If the number of indexed pages has dropped significantly, some pages may have been lost during migration. This helps you identify and fix indexation issues early.

Update your linking matrix with new URLs. Recalculate click depth for PVNs. Verify all pairings still make sense with the new structure. This ensures your matrix reflects your new site structure and remains a useful tool.

Documenting the migration helps you improve future migrations. Record what was changed, what worked, and what didn't. This creates a knowledge base for your team. Each migration should be better than the last.

The migration checklist is a list of all migration tasks from Appendix D. Use it to ensure you don't miss any steps. Print it out and work through it systematically. This prevents critical errors.

Most common migration mistakes: not running a pre-migration crawl, not creating a redirect inventory, not updating internal links directly, not testing redirects before going live, and not running a post-migration crawl. Avoiding these mistakes prevents authority loss.

Update internal links directly to the new URL. Don't rely on redirects for internal links. If you have redirect chains, shorten them to a single hop (A→C instead of A→B→C). This preserves link equity.

Run a post-migration crawl immediately after launch. Fix any 404 errors you find. Also, use 301 redirects for any URLs that have changed. Broken links waste authority and frustrate users.

Ensure every page on your new site receives at least one internal link from another page. Run a post-migration crawl to find orphan pages (Unique Inlinks = 0). Link to them or noindex them. Orphan pages are wasted content.

Ensure all PVNs are in your redirect inventory. Verify they receive links from the same sources after migration. Run a post-migration crawl to check PVN link counts. If a PVN has fewer links than before, add links to restore its authority.

The pre-migration baseline is a snapshot of your site's linking structure before the migration. It includes: all internal links, PVN link counts, click depth, and your linking matrix. This baseline helps you measure migration success.

Run a Screaming Frog crawl and export all internal links. Record PVN link counts and click depth. Export your linking matrix. Save all this data. This is your baseline for comparison after migration.

Post-migration verification is comparing your post-migration data to your pre-migration baseline. If PVN link counts have dropped, you have a problem. If click depth has increased, you have a problem. Verification ensures the migration was successful.

For each URL change, create a 301 redirect from the old URL to the new URL. Also, update all internal links to point directly to the new URL. This ensures authority flows correctly.

If content is merged, moved, or deleted, update internal links accordingly. Use 301 redirects for deleted content. For merged content, redirect old URLs to the new consolidated page. This prevents broken links and preserves authority.

If your navigation changes, ensure all PVNs are still linked from the new navigation. Add direct links to PVNs if they've been removed from navigation. Navigation changes can affect authority flow.

Design changes can affect link placement and visibility. Ensure all links are preserved in the new design. Run a post-migration crawl to verify links are still present. Design changes shouldn't break your linking structure.

CMS changes can affect how links are generated. Ensure your new CMS generates the same URLs or has redirects in place. Test thoroughly before going live. CMS changes are a common source of link errors.

Domain changes require updating all internal links to the new domain. Also, set up 301 redirects from the old domain to the new domain. This preserves external link equity and internal authority.

Subdomain changes require updating all internal links to the new subdomain. Also, set up 301 redirects from the old subdomain to the new subdomain. Subdomain changes can affect authority if not handled correctly.

Protocol changes require updating all internal links to HTTPS. Also, set up 301 redirects from HTTP to HTTPS. This preserves authority and improves security. HTTPS is a ranking signal, so this change can actually benefit your site.

Choose your preferred version (www or non-www). Set up 301 redirects from the non-preferred version to the preferred version. Update all internal links to the preferred version. This consolidates authority on one version.

Choose your preferred trailing slash convention. Set up 301 redirects from the non-preferred version to the preferred version. Update all internal links to the preferred version. This prevents duplicate content and consolidates authority.

Use lowercase URLs consistently. Set up 301 redirects from uppercase to lowercase. Update all internal links to lowercase. This prevents duplicate content and consolidates authority.

Remove query parameters from URLs where possible. Use canonical tags for pages with parameters. Ensure internal links point to clean URLs. Query parameters can create duplicate content and waste authority.

The migration timeline includes: Pre-Migration (2 weeks before), During Migration (execution day), Post-Migration (48 hours after), and Stabilization (1 month after). Plan each phase carefully. Give yourself enough time for each phase.

Share the migration plan with your team. Explain each phase and assign ownership. Use the migration checklist to track progress. Regular communication ensures everyone is aligned and no steps are missed.

Share a high-level summary of the migration plan. Explain the timeline and expected outcomes. Be transparent about risks (traffic drops, temporary issues). Regular updates build trust and manage expectations.

The migration recovery plan is a plan for what to do if something goes wrong. It includes: rollback procedures, emergency contact information, and a list of critical issues to monitor. Having a recovery plan reduces stress and enables quick fixes.

Compare pre-migration and post-migration data: PVN traffic, PVN rankings, indexed pages, click depth, orphan page count, and internal link counts. If these metrics are stable or improving, the migration was successful. If they're declining, investigate.

The rollback plan is the procedure for reverting to the old site if the migration fails. It includes: backup restoration, DNS changes, and a communication plan. Having a rollback plan gives you a safety net.

A migration typically takes 2 weeks of pre-migration planning, 1-3 days of execution, 48 hours of post-migration verification, and 1 month of stabilization. Total time: 4-6 weeks. Plan accordingly.

The stabilization period is the month after migration when you monitor and fix any issues. Traffic may fluctuate during this period. Most issues are resolved within 4 weeks. After stabilization, your site should perform as well or better than before.

Monitor your key metrics daily: PVN traffic, PVN rankings, indexed pages, and error reports. If you see issues, investigate immediately. Fix redirects, update internal links, and request re-indexing in Search Console. Quick fixes prevent long-term damage.

The post-migration audit is a full review of your site after migration. It includes: checking all internal links, verifying redirects work, ensuring PVNs are receiving authority, and updating your linking matrix. The audit confirms your migration was successful.