SEO Site Migration: A 2026 Risk Reduction Playbook

Moving a website is a controlled change to addresses, content, infrastructure, or all three. The SEO goal is to reduce avoidable disruption while helping users and search systems find the intended destinations. A careful plan improves your ability to test and repair the move; it does not promise unchanged organic traffic.

This playbook preserves the practical sequence from inventory to follow-up, with current primary guidance checked on October 4, 2026. Its transport code is a locally tested fictional exercise. No client outcome, recovery average, production migration, or complete AI citation dataset is asserted.

A site move changes the routes by which people and crawlers reach your content. A domain change adds a new hostname; a URL restructure changes page addresses; a CMS replacement can change the content, metadata, rendering, and response behavior even when the addresses stay identical. Inventory those differences before selecting a launch procedure. The name of the platform does not establish the cause of a later traffic change.

Separate transport, indexability, and performance. Transport asks whether the old address leads to the intended destination. Indexability asks whether search systems can access and consider that destination. Performance asks whether impressions, clicks, and business outcomes hold up after the move. A successful redirect check proves only the first of these. Replacing useful content with a thinner page, changing intent, or losing measurement can still produce a disappointing result.

Google’s site-move guide describes temporary search fluctuations and processing on a per-URL basis. That is a reason to plan for uncertainty, not to label every decline normal. If important pages return errors or launch with an unintended noindex, investigate immediately. If HTTP behavior and indexability checks are healthy, look at comparable demand, query groups, content changes, and reporting differences before attributing everything to the migration.

Build the inventory from more than the current navigation. Combine the CMS export, sitemaps, crawl results, server logs, analytics landing pages, and known external links. Record how each URL was discovered so another person can reproduce the scope. Include relevant image, download, and other resource addresses. A page absent from your latest sitemap can still have users and links; absence from one export is not a deletion decision.

Our planning recommendation is to give each inventory row an owner and a disposition: unchanged, moved, consolidated, or retired. Record the editorial reason for consolidations and removals alongside the technical implementation. This creates a reviewable change record and makes it possible to distinguish an intentional deletion from a missing redirect during incident triage.

For a permanent move, use an appropriate server-side permanent redirect. Google’s redirect documentation identifies 301 and 308 as permanent signals and distinguishes temporary redirects such as 302 and 307. A temporary redirect is not a permanent-move signal; its target can nevertheless be selected for indexing through other signals. Avoid turning this distinction into a claim that temporary redirects make a destination impossible to index.

Map an old page to its relevant replacement. A direct equivalent is usually the clearest destination, but useful consolidation can legitimately send several old pages to the same new page. Review that relevance with the content owner. Do not bulk-send unrelated retired URLs to the homepage. Where content is removed without a replacement, use an honest 404 or 410 response. Google’s HTTP status guidance documents that a 200 response alone does not guarantee indexing and that error-like content can be treated as a soft 404.

The following is a fictional teaching exercise, tested locally with injected mock responses. It checks an approved inventory and direct transport behavior; it neither creates redirects nor performs network requests. Absolute source and target URLs must match explicitly approved origins. Duplicate normalized sources, self redirects, credentials, fragments, and unapproved origins are rejected. Query strings remain part of the URL; decide their production mapping policy separately.

// Fictional inventory. This example performs no network requests.
export function planMove(rows, oldOrigin, newOrigin) {
  function approved(value, origin) {
    const url = new URL(value);
    if (!['http:', 'https:'].includes(url.protocol) ||
        url.origin !== origin || url.username || url.password || url.hash) {
      throw new Error('Unapproved URL');
    }
    return url.href;
  }
  const seen = new Set();
  return rows.map(({ from, to }) => {
    const source = approved(from, oldOrigin);
    const target = to === null ? null : approved(to, newOrigin);
    if (seen.has(source) || source === target) {
      throw new Error('Duplicate source or self redirect');
    }
    seen.add(source);
    return Object.freeze({ from: source, to: target });
  });
}

export async function auditMove(row, request, pause) {
  async function read(url) {
    // Illustrative budget: at most three attempts; no real fetch adapter.
    for (let attempt = 0; attempt < 3; attempt++) {
      const response = await request(url, {
        method: 'GET', redirect: 'manual',
        signal: AbortSignal.timeout(2000),
      });
      const status = response.status;
      const location = response.headers.get('location');
      const retryAfter = response.headers.get('retry-after');
      await response.body?.cancel();
      if (status !== 503 || attempt === 2 || retryAfter !== null) {
        return { status, location };
      }
      await pause(100 * (attempt + 1));
    }
  }
  const old = await read(row.from);
  if (row.to === null) {
    if (![404, 410].includes(old.status)) throw new Error('Not retired');
    return 'retired';
  }
  if (![301, 308].includes(old.status) || !old.location) {
    throw new Error('Missing permanent redirect');
  }
  const destination = new URL(old.location, row.from);
  if (destination.href !== row.to) throw new Error('Wrong destination');
  const target = await read(row.to);
  if (target.status !== 200) throw new Error('Target is not a direct 200');
  return 'transport pass';
}

Call planMove first, then pass its validated rows to auditMove with a mock request function and mock pause function. A null destination means intentional retirement. Multiple source rows may share a destination. A relative Location is resolved against the old URL and must equal the approved target before a target request is made. Unexpected destinations, temporary redirects, missing Location headers, and redirect chains fail this exercise.

The retry budget is illustrative: three attempts per URL, a two-second abort signal per attempt, and waits of 100 then 200 milliseconds. Only a 503 without Retry-After is retried. A 503 with that header, a 429, or an authentication error remains a failure for the operator to review; the code does not ignore a server’s requested delay and retry anyway. Request rejection, including an honored timeout, propagates rather than being silently converted into success. The injected request adapter must honor the signal.

This is a Node-oriented transport example. Browser manual redirects can expose opaque responses, so do not assume this checker works as a browser crawler. Responses are cancelled after headers are inspected. The example has no HTML inspection, canonical validation, robots analysis, DNS validation, concurrency controller, or production scheduling. An origin allowlist alone is not a complete defense against server-side request forgery or DNS rebinding. Keep the fixture mocked; a real checker needs a separately reviewed network adapter and destination policy.

Match the framework’s actual behavior

In the installed Next.js 16.3.5 used for this local check, the configuration below produces a permanent 308; permanent: false selects a temporary 307. These preserve the request method. Next.js redirects documentation also describes source patterns and query forwarding. Test your actual routes, query variants, base path, and hosting layer rather than assuming an example path covers them.

// Teaching configuration only: no application config is changed.
export default {
  async redirects() {
    return [{
      source: '/old-guide',
      destination: '/guides/migration',
      permanent: true, // Next.js returns 308, preserving the method.
    }];
  },
};

The configuration is an illustration, not a deployed rule. The checker’s GET requests do not establish that form submissions, authentication routes, API endpoints, or payment flows survive a migration. Assign those flows their own application tests. The locally tested exercise uses Node.js 24.21.0; Node.js fetch documentation explains its fetch API. No production traffic or live forms were used to validate this article.

Use this qualitative decision matrix to choose checks. It is an editorial planning aid, not a measured risk score or a preparation-time forecast. A small domain move with complete controls can be simpler than a same-domain rebuild that changes every template. Size, architecture, dependencies, and release constraints determine the work, so fixed week estimates are not attached to these rows.

Search Console’s Change of Address instructions applies to qualifying domain or subdomain moves after the move and redirects are in place. It excludes same-domain path changes, HTTP-to-HTTPS changes, www-to-non-www changes, and hosting changes with no visible URL change. Both properties must be owned through the same Google account. The tool does not automatically move subdomains below the submitted property; verified old variants need their own consideration.

The tool documentation describes a 180-day period for its move-specific actions and notifications. That is its stated processing window, not a promised traffic-recovery deadline. Use it as an operational follow-up item, not a countdown that authorizes dismantling your old domain or redirects. The broader site-move guidance recommends keeping redirects as long as possible, generally at least one year; continued users and old links may justify longer.

For hosting-only changes, Google’s hosting-change guide addresses preparing and testing the new infrastructure and maintaining verification. DNS changes belong to the infrastructure owner’s approved cutover and rollback plan. Agree on provider-specific cache behavior, certificates, service dependencies, and verification before the window. There is no universal TTL number in this playbook and no DNS command to copy into production.

Google recommends changing one thing at a time where practical. That does not prescribe one mandatory launch phase per changed dimension, nor a universal domain-first sequence. Distinguish preparation stages from how the live move is released. Google’s guidance favors moving small and medium sites together and permits sections for large sites; your release constraints and URL dependencies still need review.

Prepare the inventory and acceptance record

Freeze a versioned inventory, identify critical landing pages and user journeys, and assign a destination or retirement reason to each in-scope source. Include alternate hostnames and protocols in testing where they have been used. Resolve editorial disagreements before implementation. Decide who can accept exceptions, who owns the old infrastructure, and what evidence will permit a launch. A map with unresolved destinations is a planning issue, not a test that has passed.

Implement and rehearse on controlled infrastructure

Recreate templates and content, configure the approved redirects, and update navigation, canonicals, language annotations, resource references, and sitemap outputs. Compare actual responses with the frozen inventory. Use representative template and route families for detailed rendered-page checks, then run the approved transport coverage across the inventory. Record exclusions explicitly; a sample does not establish every page is correct.

Release with named decision makers

At the agreed window, the release owner enables the approved deployment and infrastructure changes. The SEO owner checks public indexability and destination annotations; the analytics owner checks collection and attribution; the application owner checks essential journeys. Use a written stop or rollback condition tied to observable faults, such as widespread failed destinations or a broken purchase journey, rather than a traffic percentage invented on launch day.

Close the move after evidence accumulates

Keep the old redirect service and its certificates maintainable. Track unresolved URLs, actual crawler requests, sitemap processing, and performance cohorts. A deployment marked successful by a hosting provider is not evidence that search systems have processed every URL. Keep launch acceptance, technical follow-up, and search-performance assessment as separate decisions in the project record.

A rollback also changes what users and crawlers see. Before launch, document which state can actually be restored, what happens to content or transactions created after cutover, and how to avoid opposing redirects. If a reversible configuration error can be fixed in the new site, weigh that repair against another move. Make this decision from the incident evidence and the agreed business criteria.

Protect staging with access controls suited to the environment and keep its ownership and indexing settings separate from production. Robots.txt is a crawl control, not a substitute for authentication. Google’s noindex guidance explains that Google must be able to crawl a page to see its noindex directive. Blocking crawling while relying on that directive is therefore not a reliable indexing-removal plan.

Before launch, inspect both response headers and rendered HTML. Check robots rules, meta robots, X-Robots-Tag, canonical destinations, language annotations, titles, descriptions, primary content, and resource loading. A header-level noindex can survive a template fix. A canonical pointing to staging can survive a hostname change. Store expected values for each template so a reviewer can identify an exception without guessing what the old version did.

Separate staging behavior from launch behavior in the acceptance checklist. Private staging may intentionally deny crawlers; the intended public destination must expose the content and indexing controls agreed for production. Test those conditions after cutover as well as before it. Inspect robots.txt and sitemaps on the public hostname, including whether a CDN is serving an older version.

Verify redirects as responses, not just as successful browser navigation. A browser can follow several redirects and hide a chain behind a working page. Check the old URL’s status and Location, the destination’s status, and its canonical and content. Test known query strings, encoded paths, case variants, trailing slashes, and previously used hostname variants according to your inventory policy. Do not automatically strip parameters that determine different content.

Use the same application acceptance criteria you would apply to any release. Check navigation, search, login, downloads, checkout, and form behavior through approved test environments. Verify analytics configuration and consent behavior with the responsible owner’s testing method; page availability does not prove collection or attribution is correct. This article’s mocked transport tests do not validate any of those business flows.

Keep an evidence bundle containing the inventory version, deployed rule version, response-check output, rendered template comparisons, unresolved exceptions, and acceptance decisions. It gives the incident team an exact state to compare against when production differs from rehearsal. Make sure the infrastructure team can still serve old redirects during new-site outages and understands the certificate and domain-renewal dependencies.

A migration can alter content access and indexing conditions that matter to search features. Google’s AI features documentation says a supporting link in AI Overviews or AI Mode must come from an indexed page eligible for a search snippet. It specifies no additional technical requirements and no special schema needed for those features. Eligibility does not guarantee selection, indexing, or a citation.

Preserve useful visible content, crawl access, and existing valid structured data that accurately describes that content. Updating entity URLs, image URLs, breadcrumb destinations, and other identifiers can be part of ordinary template parity. Do not describe schema as a universal citation switch or invent an AI citation retention percentage. Other answer services have their own behavior; Google’s eligibility documentation is not proof of their selection rules.

Server-rendered markup can simplify inspection, but JavaScript-generated JSON-LD is not inherently invisible to Google. Google’s JavaScript structured-data guide explicitly covers generating structured data through JavaScript and checking the rendered result. Compare what is actually available on the destination and use the relevant validation tools. Rendering failures, access restrictions, stale identifiers, and markup that conflicts with the visible page need separate diagnosis.

For a repeatable observation panel, record the exact prompts or queries, engine, date, language, country, account or session conditions, and cited URLs. Keep the panel stable when comparing pre- and post-move observations. Describe the result as what appeared in those checks, not the site’s total citation share. A generated answer can vary between runs even when your site has not changed.

Search Console includes Google AI-feature traffic in its overall Web reporting. It does not turn your manual citation panel into a complete traffic measurement. Review observable referral and conversion data where available, while keeping missing attribution distinct from an observed absence of citations. Our entity SEO guide provides context for consistent entity information; it does not establish a migration outcome.

Choose a pre-move comparison period that fits the site’s seasonality and available reporting history. Record its dates, filters, property scope, and known anomalies. Keep old and new property exports separately, then document how you combine them without double counting. Search clicks, analytics sessions, and completed business actions are different measures; do not substitute one for another.

Define escalation conditions with the owners before launch. A mapped destination returning an error, a public template unexpectedly carrying noindex, or a broken conversion event deserves immediate investigation. A query-cohort decline needs context about demand and content changes. Your thresholds should reflect the business, historical variability, and sample size, rather than a universal traffic-retention target.

A fictional arithmetic example illustrates the distinction: suppose a fixed cohort has 1,000 clicks in one comparison window and 800 in the next. The change is (800 − 1,000) ÷ 1,000 = −20%. That calculation does not establish the migration caused the decline. Check equal window lengths, seasonal demand, query mix, reporting delays, and changed filters before making a causal claim. These numbers describe no client, study, or observed deployment.

Track URL families rather than relying solely on a site total. A healthy homepage can mask missing documentation or product pages. Conversely, a retired section can explain an intentional count decrease. Annotate the release date and all later repairs in the monitoring record, so the person reviewing performance can connect an observed change with a specific technical or editorial event.

There is no universal number of days after which a migration has recovered. Define what recovery means for this project: technical availability, destination indexing, a particular search cohort, or business conversions. Those conditions can settle at different times. An old-URL index count declining while the replacement appears can be part of processing; a destination returning an unintended error is a fault to fix.

Google’s site-move guidance says processing speed depends on the number of URLs and how quickly the servers can be crawled. It gives a general expectation of a few weeks for most pages on small to medium sites, with larger sites taking longer. This describes URL processing, not a traffic promise or a forecast for your project. Avoid turning that broad guidance into a recovery-average chart.

Use separate status lines in the handoff: release available, transport checks accepted, indexability exceptions resolved, destination discovery observed, and performance under review. Attach the supporting evidence to each. This allows a technically complete launch to be reported honestly while search processing and performance assessment continue.

If a decline persists, start with known failure modes: response errors, irrelevant redirects, chains, crawler blocks, noindex directives, inconsistent canonicals, missing content or media, capacity problems, and broken tracking. Then inspect demand and content changes that occurred alongside the release. A correlation in time is an investigation lead, not a sufficient causal explanation.

Set the monitoring cadence according to incident severity and the reporting data you can actually observe. Review operational faults promptly; review search trends over comparable windows. Keep unresolved questions visible rather than assigning an invented recovery deadline. Maintain redirects and old-domain ownership through the agreed retention period and review real old-URL use before planning any retirement.

A useful migration playbook makes the intended changes explicit, tests their actual behavior, and preserves the evidence needed to diagnose failures. It cannot guarantee unchanged traffic. Inventory the old site, approve relevant destinations, separate permanent moves from genuine removals, and rehearse the deployment with responsible owners.

Launch with a versioned map, verified public indexing controls, working essential journeys, and comparable reporting. Keep redirects maintainable, observe destination processing, and assess search performance in defined cohorts. That gives the team a basis for repair and communication without inventing recovery statistics or treating a successful HTTP check as proof of SEO success.