Can you preserve Google rankings after changing domain or redesigning your site?
A well-planned migration can reduce the risk of losing visitors, breaking URLs and disappearing from search results, but unchanged Google rankings cannot be guaranteed. Google has to crawl and interpret the changed addresses again. Search visibility may fluctuate in the meantime. 'Without losing rankings' in the title is therefore an objective, not a promised outcome.
The biggest business mistake is usually not changing the design but losing valuable old pages, internal links and contact details without documenting them. The first question in a sound redesign is: what exactly is changing? A site that simply gets a new appearance needs different treatment from one changing its domain name or many of its URLs.
Quick rule: a page that stays at the same URL does not need a 301 just because its design changes. A page genuinely moving to a relevant new URL needs a documented permanent redirect for that address. A page removed with no successor may correctly return 404/410.
The three business pillars of migration
Protect what already works
List your important service pages and previous URLs.
Well-managed redirects
Give every important old path a genuinely relevant new destination.
Monitor after launch
Check enquiries, availability and search performance.
Six different changes — not all are domain migrations
People often use 'website migration' for six different operations. Before accepting a quote, ask the contractor to specify which one they will perform and how search-accessible URLs will be checked.
| What changes? | URL map / 301? | Search Console Change of Address? | Key check |
|---|---|---|---|
| 1. Design and UX only, same URLs | Not needed solely for this. | No. | Content, headings, internal links, forms, rendering and tracking code. |
| 2. Hosting or CDN change, same public addresses | Not needed solely for this. | No. | DNS, SSL, caching, crawler access, server responses and avoiding downtime. |
| 3. URL paths/slugs change on the same domain | Yes, for relevant URLs that have changed. | No. | 301/308, final 200, canonicals, internal links and sitemap. |
| 4. Domain or subdomain change | Yes, for content that actually moves. | Yes, if the tool's eligibility requirements are met. | Old and new property ownership, redirects, availability and URL crawling. |
| 5. Content consolidation or removal | Only to a genuinely relevant replacement; otherwise 404/410. | Not by itself. | Does the original user intent remain satisfied? Are there irrelevant mass redirects? |
| 6. HTTP→HTTPS or www→non-www on the same domain | Permanent redirects to the final preferred URL. | No. | SSL, host variations, canonicals and internal links. |
A CMS change is not necessarily a URL migration
A website can receive a new CMS without changing its domain or URLs. However, templates, headings, rendering and contact forms can easily change too. These still need testing; Search Console's Change of Address tool is not intended for this.
Old → new URL map: the migration's most important worksheet
Before development begins, request a list of every important existing URL. It should cover more than the homepage: include service pages bringing in search traffic, FAQs, contact pages and advertising landing pages. Historical Search Console data and internal navigation can help prioritise them.
Entirely fictional example using only pelda.test domains:
| Old URL | New destination | Action and test | Owner |
|---|---|---|---|
https://regi.pelda.test/szolgaltatas/villanyszereles/ | https://uj.pelda.test/villanyszereles/ | Same service: old URL 301 → new URL 200. | Developer |
https://regi.pelda.test/kapcsolat/ | https://uj.pelda.test/kapcsolat/ | 301 → 200; test the mobile form and calling function. | Developer + business owner |
https://regi.pelda.test/blog/elavult-akcio/ | No genuine replacement | 404/410; remove from sitemap and menu. | Content owner |
https://regi.pelda.test/tudnivalok/ | https://uj.pelda.test/gyik/ | 301 → 200 only if the consolidated content is truly relevant. | Editor + SEO |
What should an exportable URL worksheet include?
Alongside old and new URLs, a usable handover worksheet should have columns for the previous HTTP status, important search clicks, internal/external links, planned action, tested HTTP response at the destination, responsible person and check date. Accidental redirect chains and loops are separate failure points to watch.
Why not redirect every old page to the new homepage?
Someone looking for a 'Szolnok electrician prices' page might not find their answer on a general company introduction. Google may treat irrelevant redirects as soft 404s. Fewer permanent redirects to genuinely equivalent destinations are better; when there is no replacement, a proper 404/410 is often cleaner. The 404 error guide can help you make the right decision for each page.
Gate one — before launch: is the migration plan ready?
Ask for evidence of these four items before directing visitors to the new site:
- Inventory and priorities. Is there a list of all important URLs and pages attracting organic search traffic? Does the documentation cover contact routes and key services?
- URL mapping. Every old URL has a defined outcome: stays the same, moves to a genuine replacement, merges into relevant content or is retired correctly. Redirects do not automatically point to the homepage.
- Technical plan and access. Domain, DNS, SSL, hosting and Search Console access is available. The test environment is excluded from indexing, and its restrictions will be removed from the intended live version.
- Content and business functions. Core pages, copy, images and internal links are ready. Forms, call buttons and important customer contact routes have been tested. The owner has approved the new content.
If critical points are undocumented, delaying launch is often cheaper than trying to work out afterwards where an important page went. The guide to sitemaps, robots.txt and canonicals explains the additional content and crawler-facing technical requirements.
When it's your own business
Protect the value of your previous work during a website change
Alongside the new design, old important URLs, links and Google's processing deserve attention. Plan the migration in advance; a transition with absolutely no ranking loss cannot be guaranteed.
Gate two — at switchover: do the important routes work?
- Old URLs return the planned response. Important moved addresses return
301/308and then lead directly to the correct new page returning 200. There are no broken chains, redirect loops or accidental 404s. - New pages are actually indexable when intended. The live version must not inherit staging password protection,
noindexrules or unjustified robots restrictions. Self-referencing canonicals should use the final URLs. - Internal navigation and sitemap point to new addresses. Menus, footer, contextual links, hreflang (if multilingual content genuinely exists), structured data and XML sitemap must no longer point to the old URLs. Do not list a staging site as the live domain.
- Business contact routes have also been tested. Test click-to-call, contact details, form submissions, mobile layout, basic speed and accessibility. Check that tracking code and cookie settings work.
The Google Search Console Change of Address feature is available for certain full domain or subdomain moves when ownership and redirect requirements are met. It does not replace 301 redirects and is not a standard step for a single renamed page, a hosting-only move or a simple HTTP→HTTPS change.
Gate three — after launch: what actually changed?
- Record the initial state and any errors. Check old and new addresses, redirects and the response codes of key landing pages. Keep a fix log instead of judging from memory.
- Monitor Search Console reports. Watch indexing of important pages, search performance, sitemap processing and crawl errors. Reports can be delayed; not every change appears immediately.
- Compare meaningful periods. Track changes to old and new URLs, search clicks, impressions and actual business enquiries. Account for seasonality and demand rather than relying on a single day's chart.
- Make documented fixes and keep redirects in place. Google recommends keeping redirects for at least a year; they often benefit visitors for longer. Update important links from external profiles and, where possible, significant inbound links.
Launch is not a one-off task: monitor the new site while search systems process the changes. Even a smaller site may take weeks and larger ones longer; this is guidance, not a guaranteed timetable or ranking recovery.
Eight things you might see after migration — each needs a different response
| What you see | What to investigate |
|---|---|
| An old URL still appears on Google | Is the redirect correct, and has Google processed the migration yet? This is not necessarily a problem during transition. |
| An important new page is not indexed | URL Inspection, noindex, canonical, internal link and indexing status. See our detailed indexing diagnostics. |
| An old service link returns 404 | Is there a suitable new destination? Is it a broken redirect or an intentional removal? |
| Every page redirects to the homepage | Risk of irrelevant bulk redirects and soft 404s; correct the URL mapping. |
| Search Console or GA4 shows no data | Correct property access, working tracking code, time zone and reporting delays. |
| No quote request or call button on mobile | Responsive components and conversion flow; treat as a business priority. |
| Only a few queries dropped | Filtered search reports, content and relevance; not automatically a site-wide technical problem. |
| Every important page returns 5xx | Hosting, DNS, CDN, server logs and crawler access: urgent developer investigation. |
If Google traffic has changed significantly, use the targeted traffic drop checklist to distinguish measurement differences from possible technical or content causes.
What documentation should the contractor hand over?
A website handover should involve more than a login link and an invoice. To reduce risks, request documentation you can verify and take away:
- the final ownership and access arrangements for the domain and hosting, with the required roles;
- the old-to-new URL mapping, reasons for retired addresses and full redirect list;
- HTTP and canonical test results for key pages, and the final sitemap location;
- test records for forms, call buttons, mobile menu and analytics;
- Search Console property status and, only where relevant, Change of Address status;
- who is responsible for maintaining the redirects, what they cover and follow-up dates;
- an issue log showing what is finished, outstanding, and who will fix it by when.
In particular, your business domain and other digital assets should not be tied exclusively to the contractor's personal account. Access roles must be clear, and required passwords should be handed over securely.
Frequently asked questions about domain migration and SEO
Can you guarantee that my Google rankings won't fall at all?
No. Good planning reduces risk, but fluctuations can happen as Google reprocesses changes and competitors continue to compete.
We're only changing the design. Do we need 301 redirects?
Not if the public URLs remain the same. Content, internal links, rendering and contact functions still need thorough testing.
If we move hosting, should we use the Change of Address tool?
Generally not if the public domain and URLs remain unchanged. The tool applies to certain domain or subdomain moves under specific conditions.
How long should we keep 301 redirects?
Google recommends at least one year. For user experience, it is often sensible to keep them longer or even indefinitely.
Is submitting the new sitemap enough?
No. Sitemaps help discovery but do not replace proper server-side redirects, working internal links, indexability and content checks.
Sources and professional references
Related guides
Next step · Kaluzsa
Thinking about a redesign but worried about being found?
Let's discuss the goals of your old and new websites and the risks of changing over. A well-managed migration can prevent avoidable errors.