Four kinds of move, four different risks
A migration is any change that alters what search engines find at your existing addresses. The risk depends on what changes.
Redesign with the same URLs
The lowest risk, though a new design can still lose internal links, copy, headings and titles.
Redesign with new URLs
Every changed address needs a redirect, and the new structure must reflect the old pages that mattered.
Domain change
A rebrand or merger. Everything moves at once, so the redirect plan has to cover the whole site.
Platform move
A new system often changes URL patterns, templates and default settings, sometimes in ways nobody notices until traffic drops.
Why involve SEO before the design is approved
Most migration damage is baked in long before launch. A new design removes a page that earned enquiries, a developer shortens every address, or a template drops the title text. By the time traffic falls, the cause is hard to trace.
Google's guidance for a site move with URL changes begins with a map of old to new URLs, built from sitemaps, server logs, analytics and the CMS, and including images and files. That step needs the full picture of the old site, so it is best done while the new site is still a plan.
What a redirect map looks like
The map is a simple spreadsheet, but every row is a decision. We keep it as a single source of truth during the build.
| Old URL | Action | New URL or reason |
|---|---|---|
| Page that still exists at a new address | Permanent redirect | The matching new page, directly, with no stops in between |
| Two old pages merged into one | Permanent redirect | The single combined page |
| Old page with no replacement | Allow a not-found response | Nothing relevant exists, so sending visitors elsewhere would mislead them |
| Old file, image or document | Redirect or keep in place | The new file location, if it earns traffic or links |
| Tracking or parameter variants | Decide per case | Usually the clean canonical address |
Redirect rules we apply
These come from Google's documentation on site moves, along with what we check on every launch.
- Use server-side permanent redirects: Google recommends 301 or 308 redirects where technically possible.
- Avoid JavaScript redirects: Google says to reserve them for cases where a server-side redirect is impossible, since a failed render means it may never see the redirect.
- Send each old URL to its final destination: Avoid chains, and if one is unavoidable keep it short, ideally no more than 3 redirects.
- Do not dump everything on the home page: Google advises against redirecting many old URLs to one unrelated page.
- Keep redirects in place for a long time: Google suggests keeping them as long as possible, generally at least a year.
- Update internal links: Links on the new site should point to the new addresses directly, not through redirects.
What to ask your developer or web agency for
Many migrations go wrong in the brief, not the build. Put these requests in writing before work starts.
- Change one thing at a time: Google advises splitting a move into smaller steps where that makes sense, and not changing more than one thing at once.
- Keep the old URL list: Gather addresses from sitemaps, server logs, your CMS and Search Console's links report, including images and files.
- Keep staging out of search: Prepare the launch robots.txt, and list every page where a development noindex tag must be removed.
- Verify both sites in Search Console: Do this for every variant of the old and new domains before launch.
- Choose a quiet week: Google suggests timing a move for a low-traffic period.
- Test the redirects: Check them after switching them on, using the URL Inspection tool or scripts.
How a migration runs from plan to aftercare
The timeline is built around the launch date, with work before and after it.
- Record the old siteWe list the pages, titles, headings, links and enquiries tied to the pages that matter, so we can compare later.
- Agree the new structureWe check that every important old page has a place in the new design.
- Build the redirect mapEach old address gets a destination or a deliberate decision to retire it.
- Test on stagingWe review the new site for titles, headings, links, canonical tags and anything that blocks search engines.
- Prepare launch dayA checklist covers redirects, the sitemap, robots rules and the removal of any development-only blocks.
- Monitor after launchWe watch indexing, errors and traffic to the old and new addresses, then fix what appears.
Domain change: extra steps
A change of domain adds a step Google describes as a Change of Address in Search Console. It applies only when moving domains or subdomains. Google says you do not need it for an HTTP to HTTPS move, a www to non-www change, or path changes within the same domain.
For a domain migration, Google advises submitting it for all verified variants of the old domain, even inactive ones. That means the site owner needs a verified property for each. If you do not hold that access, sort it out before launch, because it takes time to arrange.
Brand change is also a good time to check name consistency elsewhere, including your listing on Google Maps, which we cover in Google Business Profile work.
Launch checks and what to expect afterwards
Google says rankings can fluctuate while it recrawls and reindexes a moved site. Medium-sized sites can take a few weeks or more to show new URLs, and larger ones take longer.
Check on launch day
- Remove noindex tags and robots.txt blocks left from development
- Submit a sitemap with the new URLs
- Confirm each key old address redirects once, to the right page
- Check that each new page has a self-referencing canonical tag
Be wary after launch
- Treating a short dip as proof the migration failed
- Removing redirects after a few weeks
- Changing more things at once, which makes the cause harder to trace
- Ignoring new error reports in the first weeks
Who tends to need this and what to read next
Stores face the sharpest risks, since a platform move can change thousands of product and category URLs. Our work for ecommerce SEO looks at how those pages are structured, and ecommerce store SEO covers how shoppers find them.
Professional services firms move for different reasons, such as a merger or rebrand. Practices that list separate pages for each lawyer or practice area, covered in law firm SEO, need those pages mapped carefully so none are lost.
Before a move, an SEO audit gives a baseline, and technical SEO work can fix crawl or index problems on the old site first. The full list of services shows where migrations sit alongside them.
Businesses serving a particular district, such as those in Tuggeranong, should check that location wording and contact details carry across unchanged.
Frequently asked questions
Will I lose rankings if I redesign my website?
Not necessarily. Risk rises when URLs, titles, headings or internal links change. Google says rankings can fluctuate while it reprocesses a moved site. A careful plan reduces the problems, but we do not promise rankings will be unchanged.
When should I involve an SEO before a new website?
As early as possible, ideally before the design is approved. The most useful work, such as listing pages that earn enquiries and mapping old to new URLs, depends on knowing the old site and still being able to influence the new one.
Do I need a redirect for every old page?
Every old page that has a relevant new equivalent should redirect directly to it. Pages with no equivalent can return a not-found response. Google advises against sending many old URLs to one unrelated page such as the home page.
How long should redirects stay in place?
Google suggests keeping them for as long as possible, generally at least one year. For pages with links from other websites, we usually suggest leaving them indefinitely unless there is a strong reason to remove them.
Is changing from HTTP to HTTPS a migration?
Yes, in the sense that URLs change. Google says a Change of Address is not needed for that move, but redirects, canonical tags and internal links still have to be updated. The same applies to a www to non-www switch.
Can you help after a migration has already gone wrong?
Yes. We compare the old and new sites, find missing redirects, blocked pages and lost content, and give you a prioritised fix list. Recovery depends on how long the problem has been live and what was lost, so we cannot promise a timeline.
Do you build the new website?
No. We work alongside your designer or developer, supplying requirements, the redirect map and checks. If they need clarification on any SEO point, we can speak with them directly during the build.
Sources and further reading
- Site moves with URL changes: URL mapping, permanent redirects, chains, Change of Address, retention period, fluctuations, sitemaps and blocking checks
- Google Search Central: Redirects and Google Search: Permanent and temporary redirect types; JavaScript redirects only when server-side is not possible