How to Prevent SEO Loss During a Website Redesign: URL Migration Guide

The practical way to reduce avoidable SEO loss during a website redesign is to measure the old site before launch, make an explicit decision for every URL, and manage redirects, canonicals, sitemaps and analytics as one migration plan. A working homepage is not evidence of a successful migration.

This guide does not promise zero traffic loss. Google explains that crawling and indexing a move can produce temporary fluctuation. The goal is to detect preventable risks such as omitted URLs, irrelevant targets, redirect chains, residual noindex rules, conflicting canonicals and broken measurement.

Classify the Change Before Planning the Migration

If a project changes templates and design on the same domain, preserving useful URLs usually keeps the migration surface smaller. When URL structure, domain, protocol, subdomain, language folders or information architecture change, search systems must process the relationship between old and new addresses.

Google’s site move documentation recommends mapping old and new URLs, testing redirects, submitting a new sitemap and monitoring the move in Search Console. Changing the domain, content platform, visual design and content strategy at once can make diagnosis harder. Record each necessary change with an owner and acceptance test.

Use the website redesign decision guide first when the redesign decision itself is not settled.

What Is the SEO Migration Evidence Pack?

The Kumsal SEO Migration Evidence Pack is an original project-control framework that replaces a single “launched” status with five evidence groups. It is not a ranking model or guarantee; it gives content, development, analytics and business owners one traceable record.

1. Pre-launch baseline: crawlable URL inventory, priority landing pages, query and traffic view, meaningful conversion or enquiry events, index status and server responses.
2. Old-to-new URL map: every old URL, new target, decision reason, content equivalence, redirect type, canonical, locale counterpart and owner.
3. Launch acceptance evidence: 200 responses on new pages, correct 301/308 or intentional 404/410 outcomes for old addresses, chain and loop checks, robots/noindex, canonicals, sitemap and analytics.
4. T+1, T+7 and T+30 checks: next-day accessibility, first-week crawling and priority pages, then thirty-day trends, remaining old URLs and corrective decisions.
5. Change log: finding, affected page group, correction, date, owner and retest result.

The pack cannot eliminate reporting delays. It helps teams separate technical failures from ordinary changes in demand, seasonality or campaigns by comparing the same periods and page groups.

How Should the Pre-Launch Baseline Be Recorded?

Crawl the current site before migration and do not rely only on its sitemap. Navigation, organic landing pages, inbound links, campaign URLs, PDFs, images and language versions can expose different inventories. Record status, canonical, indexability, title, locale and the planned decision for every relevant URL.

The measurement baseline should preserve priority page groups, organic clicks and impressions, branded and non-branded query groups, real business events such as form or quotation completion, and a view of server errors. Do not expand personal-data collection. Record date ranges, filters and expected reporting delays.

Which Fields Belong in the Old-to-New URL Map?

Useful columns include old URL, current response, traffic or link importance, new URL, decision type, content equivalence, redirect code, canonical target, TR/EN counterpart, test result and owner. Separate decisions into:

• Keep: content and URL remain available.
• Move: a permanent redirect goes to a new URL satisfying the same intent.
• Consolidate: several old pages go to one target that genuinely covers their content.
• Retire: an honest 404 or 410 is returned when no equivalent exists.
• Hold: the URL stays outside launch scope until a business or legal decision is complete.

Do not redirect unrelated pages merely because they share terms. Google’s redirect documentation identifies server-side permanent 301 and 308 redirects as appropriate methods for permanent moves. Build direct targets and test chains, loops and self-redirects.

How Should Canonicals, Redirects and Sitemaps Agree?

A 301 communicates that an old address moved permanently. A canonical states the preferred URL among accessible duplicate or similar pages. A sitemap presents the canonical URL set intended for crawling. These mechanisms do not substitute for one another.

Google’s canonical guidance describes redirects and rel="canonical" as strong signals and sitemap inclusion as weaker, noting that signals can be combined. If an old URL redirects to a new page, the new page should normally self-canonicalise, the sitemap should list the new canonical URL, and internal links should point directly to it.

Google’s sitemap documentation calls for fully qualified absolute URLs and recommends listing canonical URLs. Sitemap inclusion does not guarantee indexing; it helps keep discovery and preference signals consistent.

How Should Multilingual URLs Be Migrated?

Map Turkish and English URLs as separate rows while retaining the relationship between real counterparts. Each locale page should self-canonicalise, and hreflang should connect only published equivalents. The language control should open the corresponding content, not a category or homepage.

Do not send a retired locale page to unrelated content in another language. Test redirect, canonical and hreflang decisions together so a technically valid response cannot hide a wrong-language or wrong-task journey.

Launch-Day Acceptance Checks

• Are DNS, TLS, primary templates and priority pages available?
• Do new URLs return the expected 200 response?
• Do representative old URLs go directly to the correct target with 301/308?
• Are robots.txt, meta robots and HTTP headers free of accidental blocks?
• Do canonicals and hreflang point to real published URLs?
• Does the sitemap contain the new canonical set and load successfully?
• Do internal links reach new targets without consuming redirects?
• Do forms, calls, commerce or quotation events reach their real systems?
• Are 404, 5xx, redirect-chain and loop crawls clean?
• Can the verified rollback plan be used if required?

Combine these controls with access, backup, form, analytics and ownership checks from the corporate website handover checklist.

The T+1, T+7 and T+30 Monitoring Plan

T+1: Availability and measurement

Retest representative priority, new and old URLs. Confirm analytics events, form delivery, sitemap access and Search Console properties. Prioritise template-level defects that affect an entire page group.

T+7: Crawling and priority pages

Review old URLs still being crawled, discovery of new URLs, 404/5xx clusters, canonical selection and the performance of priority landing pages. Avoid conclusions based on a single day; compare like-for-like page and query groups.

T+30: Trends and remaining debt

Reassess traffic and links reaching old addresses, redirect chains, canonical pages missing from the sitemap, locale relationships and business events. For a declining page, separate technical accessibility from content equivalence before assuming every change is a redirect failure.

Ensure that the agency or maintenance provider receives the access, configuration, redirect inventory and analytics ownership needed to maintain this evidence after launch.

Common SEO Migration Errors

• Using only the new sitemap without crawling old URLs
• Redirecting every old page to the homepage or one category
• Creating 301 chains or protocol and domain loops
• Leaving staging noindex or robots blocks on production
• Keeping an old URL as canonical on a new page
• Sending locale counterparts to category pages
• Leaving internal links and image references on old addresses
• Checking the analytics tag but not real form delivery
• Interpreting traffic change without a pre-launch baseline
• Removing redirects early or leaving them without an owner

What Should an Agency or Development Team Deliver?

A proposal should name the URL inventory and mapping owner, redirect implementation method, canonical/hreflang/sitemap rules, test coverage, analytics and Search Console access, launch responsibilities, rollback conditions, and T+1/T+7/T+30 reports. “SEO-friendly migration” is not an acceptance criterion by itself.

Use the corporate website content matrix to assign each page an audience, content owner and place in the new architecture.

Conclusion

SEO migration risk is not managed by writing a few 301 rules on launch night. It requires a measurable baseline, row-level URL decisions, aligned canonical and sitemap signals, working analytics and scheduled checks. The SEO Migration Evidence Pack keeps these responsibilities in one traceable record.

To assess a website redesign, content migration and technical SEO transition, contact Kumsal Agency’s web design team.