Use permanent redirects for permanent URL moves
For a permanent domain move or URL restructuring, use permanent redirects from old addresses to their intended replacements. Google Search Central identifies server-side HTTP 301 and 308 redirects as permanent-move options and explains that permanent redirects signal that the destination should be canonical.
The role of redirects in SEO and site migration is therefore more than getting a visitor to another page: Google Search Central describes certain redirect types as signals that influence which URL appears in search results. Treat that as a canonical-selection signal, not a promise that every ranking or visit will remain unchanged.
Start with two decisions: whether the move is permanent and which page should replace each old address. Keep those decisions separate from the mechanics of configuring the redirect. A technically correct response is not enough to approve a migration if it sends readers to the wrong content.
Choose the redirect type that matches the move
Google Search Central’s redirect guidance recommends permanent redirects when you are sure the move will not be reversed. For a lasting domain change or a lasting change to page addresses, specify a server-side 301 or 308 in the implementation plan.
Google Search Central lists HTTP 302, 303, and 307 as temporary redirects that Googlebot follows without treating the redirect itself as a signal that the destination should be canonical. Google Search Central also notes that other canonicalization signals may still lead to the destination being indexed.
Use the expected lifetime of the change to make the choice. As an illustrative example, a page temporarily replaced during maintenance calls for a different decision from a page permanently relocated into a new directory. Record the intended behavior explicitly rather than approving whichever response a migration tool happens to produce.
Google Search Central also lists zero-second meta refresh as a permanent redirect method and says to use JavaScript redirects only when server-side or meta refresh redirects are not possible. If the platform cannot produce the server-side response you planned, resolve that limitation before substituting a different method.
Do not judge the redirect type solely by watching a browser arrive at the new page. Google Search Central notes that users generally cannot distinguish redirect types, even though Google Search uses certain types differently as canonical signals. Inspect the actual response as part of testing.
Map old pages to deliberate destinations
Build a migration map before writing broad redirect rules. For each old address, record the intended destination, the permanent-or-temporary decision, and a short explanation of why that destination is appropriate. Use the map as the specification against which you test the deployed behavior.
The following are illustrative mapping decisions, not automatic rules or predictions of search performance. The key question is what a reader requesting the old page should find after the move.
| Illustrative change | Proposed destination | Acceptance check |
|---|---|---|
| An article moves into a different site directory | The same article at its new address | The destination contains the intended article, not just a category listing. |
| A domain changes while page content is retained | The corresponding page on the new domain | The destination uses the intended domain and serves the corresponding content. |
| Several articles are deliberately combined | The consolidated article | An editor confirms that the combined page addresses the relevant subject of each old article. |
| A page is removed without a clear replacement | No destination approved yet | Return the row for a content decision rather than assigning an unrelated page by default. |
For repeatable address changes, test a proposed pattern against the map and set aside exceptions. For example, do not assume every old page has the same name on the new site merely because most do. Approve a pattern only after its proposed destinations match the content decisions; handle the remaining pages individually.
Use the same destination map when reviewing internal linking for SEO and navigation. Set your migration acceptance criterion to links that point directly to the intended new pages, and check navigation, article links, and reusable page components against that criterion.
Test the response and the destination separately
Give the implementer both the redirect map and the expected response type. Keep a test record with the old address, expected destination, observed response, observed destination, and result. This separates a configuration mistake from a disagreement about which content should replace the old page.
- Inspect the response from each old address with an HTTP inspection tool or the browser’s network panel. Compare the observed status with the status specified in the map. If they differ, correct the configuration and repeat the request.
- Compare the redirect destination with the approved destination. Check the domain and page address, not just the visible page title. If the redirect points elsewhere, revise the affected rule or mapping entry.
- Follow the complete route to the final page. Use a direct old-to-approved-destination route as your implementation target. If the request passes through unintended intermediate addresses or returns to an earlier address, trace and revise the rules involved.
- Open the final page and inspect its content. Accept the row only when the intended article, product information, or other approved replacement is actually present. If the address is correct but the content is wrong, resolve the content deployment rather than changing the redirect blindly.
- Retest related pages after changing a shared rule. Include both pages intended to match the rule and pages intended to remain outside it. Record any mismatch and narrow the rule before approving that group.
- Repeat the checks against the live migration after deployment. Compare live results with the approved map rather than assuming a successful pre-launch test describes the production configuration.
Keep failures specific. “Old article redirects to the category page instead of its replacement” gives an implementer a concrete correction. “Migration SEO looks wrong” does not identify whether the problem is the response, the destination, or the content.
Maintain a separate exception list for unresolved content decisions. Do not mark those rows as technically complete simply because a redirect exists. The acceptance condition is the agreed route to the agreed replacement, not the presence of any redirect.
Prepare the destination server for additional crawling
Google Search Central’s site migration guidance explains that Google will temporarily crawl the new site more heavily because crawls of old addresses are redirected there in addition to other crawling. Include the destination server in migration preparation, not just the redirect configuration.
Google Search Central recommends ensuring that the new site has capacity for the additional traffic and notifying hosting providers in advance for particularly large moves. Ask the hosting or infrastructure team to assess the planned migration against the destination environment rather than assuming its normal workload is the only relevant load.
- Identify who can review destination-server load and errors during launch, and who has permission to make capacity or configuration changes.
- Agree on the monitoring views and operational thresholds with the hosting team; use thresholds appropriate to the actual environment rather than a generic migration number.
- Test the destination under a workload chosen with the infrastructure team. If the test produces failed requests or exceeds the agreed thresholds, address that result before launch.
- Prepare an escalation action for live overload: name the responsible person, the observed condition that triggers contact, and the capacity or configuration options available.
Separate redirect faults from search visibility changes
After launch, keep implementation checks and search measurement as separate workstreams. First establish whether requests follow the approved map. Then examine how the moved content appears in search and receives traffic. Do not use a traffic chart alone to decide which redirect rule needs editing.
- If the response, destination, or content fails, return to the live-retesting procedure above and record the affected mapping row.
- If requests fail alongside server-load problems, involve the infrastructure owner and compare the observations with the agreed operational thresholds.
- If the route and content pass but search visibility differs, record the affected pages. Compare whether the old and replacement addresses are indexed and which address appears in search. Compare impressions and clicks over comparable periods before and after deployment, noting whether changes affect individual pages or broader groups. Do not label the redirect defective solely because visibility changed.
For measurement, group old and new addresses by the same underlying content. As an example, compare a moved guide and its replacement together rather than treating the old address’s decline as the whole result. Keep a dated record of deployment and subsequent corrections so that each comparison has a clear reference point.
Choose SEO metrics worth tracking around a concrete question: are the moved pages receiving search impressions, clicks, and visits, and which page groups need investigation? Keep those observations alongside the redirect test record without treating either dataset as a substitute for the other.
