Website · THE NO-PANIC PLAN
Migrate a website with URL changes and verified redirects
Changing a domain or URL structure is a per-page migration project, not just a server switch. This workflow builds a reviewed old-to-new URL map, tests destination pages and permanent redirects, updates internal links and canonical tags, submits the new sitemap, and monitors both sites after launch. Nirmion's Redirect Map Generator validates explicit URL pairs and exports a reviewable CSV; it does not create or deploy redirects. The guide applies to migrations where page URLs change. If only hosting or infrastructure changes while URLs stay the same, use a hosting-move plan instead. Search visibility can fluctuate while crawlers process the move, so no ranking outcome or completion date is guaranteed.
MISSION Move a website to new URLs while maintaining useful page mappings, working redirects, crawlable replacement pages, and measurable migration checks.
Build and review a website migration URL mapTHE REAL-WORLD BIT
What happens outside this browser tab?
Inventory the old URLs and plan one migration variable at a time; prepare and test the new site; map each old URL to its closest equivalent or an intentional retired-page response; validate the map; implement and test redirects in staging; launch with updated internal links, canonical URLs, robots directives, and sitemap; then monitor traffic, crawl errors, and old/new URL behavior while keeping redirects in place.
YOUR CHECKLIST, WITH FEWER DRAMATIC SIGHES
One step at a time.
Follow the order below. If a step names a Nirmion tool, its link is right there with it.
- 01
Define the migration scope and preserve a baseline
Write down what is changing: domain, protocol, path structure, or a combination, and identify any simultaneous hosting, CMS, redesign, or content changes. Google recommends changing one major thing at a time where possible because combined changes are harder to diagnose. Export the current URL inventory, sitemap, analytics and Search Console baselines, important inbound links, and known redirect rules. Confirm ownership and access for both old and new Search Console properties. If URLs will not change, this URL-migration guide is not the right process; follow the separate hosting migration guidance. (Sources 1, 2, 5)
- 02
Prepare the new site and test representative pages
Build the new site on a protected staging host and verify representative page types, navigation, forms, assets, authentication, mobile layouts, and server responses before changing public traffic. Check that intended new pages return successful responses and that staging-only password protection, noindex directives, or robots.txt blocks are deliberately removed or changed for launch. Keep the page content and site structure as stable as practical during the URL move so you can isolate migration issues. Confirm server capacity and a rollback owner before scheduling the change. (Sources 1, 2, 6)
- 03
Map each old URL to its relevant new destination
Create one row for each old URL and its intended replacement. Send a URL to the closest equivalent page that serves the same user need; do not send unrelated retired pages to the home page. Mark removed pages that have no equivalent for an intentional 404 or 410 response according to the site's policy. Include the expected status, destination, page owner, and any query-string or locale rules that matter. Use Nirmion's Redirect Map Generator to validate explicit source-to-target pairs and export a reviewable CSV, then have a site owner inspect ambiguous or high-traffic mappings. The tool does not install or activate redirects. (Sources 1, 3)
- 04
Implement redirects and test the map before launch
Ask the server or CMS owner to implement server-side permanent redirects for URLs that have a genuine replacement, using the approved map and the platform's supported configuration. Google recommends permanent server-side redirects where possible; avoid long chains and point directly to the final destination. Test a sample across old protocols, host variants, important paths, query strings, trailing-slash rules, and representative page types. Verify status codes and Location headers, that targets resolve successfully, and that no loops or irrelevant redirects occur. Treat method-sensitive application endpoints separately; redirects on API or form POST routes need engineering review. (Sources 1, 3, 4)
- 05
Launch with consistent links, canonicals, robots rules, and sitemap
At cutover, update internal links and navigation to point directly to the new URLs, set each replacement page's canonical URL to the intended new address, and confirm robots.txt and page-level robots directives allow the pages meant for search to be crawled. Publish a UTF-8 sitemap containing absolute canonical new URLs and submit it through Search Console. If the move is between domains, use the Search Console Change of Address tool only after the site is moved and redirected, and only when its domain-property requirements are met; it is not for an HTTP-to-HTTPS move or an internal path-only move. (Sources 1, 2, 5, 6)
- 06
Monitor old and new URLs after cutover
For the first hours and days, check that important old URLs redirect to the expected live pages, new pages return the intended response, and analytics and key user journeys work. Compare traffic, crawl activity, indexing and not-found reports for both properties against the baseline. Inspect examples of old URLs that still appear in logs or external links and repair missing mappings or redirect chains. Search Console data and crawling take time to reflect a move; temporary search fluctuations can happen, and sitemap submission is a discovery hint rather than a guarantee of indexing. Escalate server errors or material user-facing failures using the rollback plan. (Sources 1, 2, 5, 6)
- 07
Keep redirects and close the migration deliberately
Retain old-to-new redirects for the period required by the platform, business, and search guidance. Google's current domain-move help says to maintain redirects for at least 180 days and longer if Google Search traffic still reaches them; its site-move documentation recommends keeping redirects as long as possible, generally at least a year. Keep the old domain registered according to your security and business policy, update high-value external links where practical, and track unresolved old URLs. Close the migration only after the owner reviews operational metrics, user reports, crawl errors, and the redirect map; do not declare success based solely on the new sitemap being accepted. (Sources 1, 2, 5)
THE HELPER CREW
Tools for the fiddly bits.
These are the currently published Nirmion tools matched to this guide. Open a tool page for its accepted inputs and limits.
RECEIPTS, PLEASE
Sources & review notes
Each source is linked to the steps it supports. Open it to check its scope and current guidance.
Source checked 2026-10-10