The migration
How to Keep Your Google Rankings Through a Rebuild
The redirect work that decides whether years of ranking history transfers or disappears.
Part of the Real Estate Website Rebuilds guide · Last reviewed 2026-08-09
Keeping rankings through a rebuild comes down to one thing: every address that had value must point permanently at the page that replaces it. Google's documentation states that permanent redirects, meaning 301 and 308, are used by the indexing pipeline as a signal that the redirect target should be canonical, while temporary redirects are followed but not used that way. Google also recommends keeping redirects for at least a year so it can transfer all signals, including reassigning links from other sites. Everything else in a migration is secondary to getting that mapping complete and correct.
Key takeaways
- Permanent redirects (301, 308) pass canonical signals. Temporary ones (302, 303, 307) are followed but do not.
- Google recommends keeping redirects at least a year, and suggests indefinitely for visitors arriving from old links.
- For smaller sites Google recommends moving all URLs at once rather than section by section.
- Google says to change internal links to point at the new addresses rather than leaving them to redirect.
- Submit the new sitemap in Search Console, and use Change of Address when the domain changes.
- Google says to use a JavaScript redirect only when server-side or meta refresh redirects are impossible.
Start with a complete inventory, not a design
You cannot redirect a page you do not know about, and the pages most often forgotten are the ones nobody on the team thinks about: an old market update, a neighbourhood guide written years ago, a listing page that picked up a link from a local news site.
Build the list from more than one place, because no single source is complete. Search Console shows the addresses Google has indexed and which earn impressions. Your analytics shows what people actually visited. The existing sitemap shows what the site claims exists. Combining them catches pages that any one source misses.
Do this before design work starts. Once a new structure is agreed, the inventory stops being a discovery exercise and becomes an argument about what to leave behind.
Map every old address to exactly one new address
The mapping is one row per old address, with the new address it should lead to. One destination, not several. If two old pages genuinely merge into one new page, both point at the merged page, which is fine and normal.
The rows that need judgement are the ones with no obvious destination. A page can be recreated, merged into a related page, or dropped. Dropping is a legitimate choice for a page with no traffic and no links, as long as it is a decision rather than an omission. Sending it to the homepage instead is worse than dropping it, because a redirect to an unrelated page does not preserve the relevance that made the original rank.
Use permanent redirects, and test them before the old site goes away
Google's redirect documentation is explicit about the difference. With a permanent redirect, "Googlebot follows the redirect, and the indexing pipeline uses the redirect as a signal that the redirect target should be canonical." With a temporary redirect, "Googlebot follows the redirect, but the indexing pipeline doesn't use the redirect as a signal that the redirect target should be canonical."
Google recommends server-side permanent redirects where possible. It treats an instant meta refresh as a permanent redirect, and says to use JavaScript redirects only when server-side or meta refresh options are unavailable, warning that Google might never see one if rendering fails.
Test against the real inventory, not a sample. Request every old address and confirm it returns a permanent redirect to the intended destination. Doing this before the old site is decommissioned means mistakes are still cheap to fix.
Update internal links rather than relying on redirects
Google's site move guidance says to change the internal links on the new site from the old addresses to the new ones. Redirects exist for links you do not control, such as those on other people's sites. Links inside your own site you do control, so they should point at the destination directly.
The same applies to anything else you own that points at the old addresses: your Google Business Profile, email signature, social profiles, and any listing portal profile.
Tell Google, then watch
Submit the new sitemap in Search Console, which Google says helps it learn about the new addresses. If the domain is changing, submit a Change of Address for the old site. Google notes that a move from HTTP to HTTPS on the same domain does not need that tool, though redirects still apply.
Then monitor. Google says a small to medium-sized website can take a few weeks for most pages to move, that larger sites take longer, and that visibility may fluctuate temporarily before settling. What you are watching for is not a flat line, it is whether the new addresses are being indexed and whether anything is reporting errors.
Decide the move shape by site size
Google gives different advice depending on scale. For smaller sites: "We recommend moving all URLs on your site simultaneously instead of moving one section at a time," because it helps users and helps Google's systems detect the move and update the index faster.
For larger sites, moving one section at a time is acceptable and "can make it easier to monitor, detect, and fix problems faster." Most single-agent and small-team sites are firmly in the first category, so the phased approach that sounds cautious is not what Google recommends for them.
| Step | What it prevents |
|---|---|
| Export indexed addresses from Search Console | Redirecting only the pages you remembered |
| Add analytics and sitemap addresses to the list | Missing pages Google indexed but you never linked |
| Map each old address to one new address | Bulk redirects to the homepage that lose relevance |
| Implement as permanent (301 or 308) redirects | Signals not transferring to the new address |
| Test every old address before decommissioning | Discovering broken redirects weeks later |
| Update internal links to the new addresses | Relying on redirects for links you control |
| Submit the new sitemap in Search Console | Slower discovery of the new addresses |
| Submit Change of Address if the domain changed | Google treating it as two unrelated sites |
| Keep redirects at least a year | Cutting off signal transfer before it completes |
Frequently asked questions
What is the difference between a 301 and a 302 redirect?
A 301 is permanent and a 302 is temporary, and Google treats them differently. With a permanent redirect the indexing pipeline uses it as a signal that the target should be the canonical address. With a temporary redirect Googlebot follows it but does not use it as that signal. For a rebuild where the old address is never coming back, permanent is the correct choice.
Can I redirect all my old pages to the homepage?
You can, but it discards the relevance that made those pages rank. A redirect works best when the destination covers the same subject as the original, because that is what makes it a genuine replacement. For a page with no equivalent, letting it return a 404 is more honest than sending someone looking for a specific neighbourhood guide to a general homepage.
How long do I need to keep redirects in place?
Google's guidance is at least one year, because that is what allows it to transfer all signals to the new addresses including recrawling and reassigning links from other sites. It also suggests keeping them indefinitely from a user perspective, since people still arrive from old bookmarks and third-party links long after search engines have adjusted.
Should I move my whole site at once or in phases?
Google recommends moving all URLs simultaneously for smaller sites, because it helps its algorithms detect the move and update the index faster. Phased moves are the recommendation for larger sites, where doing it in sections makes problems easier to monitor and fix. Most agent and small brokerage sites should move all at once.
Do I need the Change of Address tool in Search Console?
Use it when you are moving to a different domain. Google says it is not needed for a move from HTTP to HTTPS on the same domain, although the redirects still apply in that case. It works alongside redirects rather than replacing them.
What if my new site has fewer pages than the old one?
That is common and manageable. Merge related old pages into the new page that covers the same ground and redirect them all there. The pages needing a real decision are those covering something the new site does not address at all: recreate the content, or accept losing whatever that page earned. Just make it an explicit choice rather than something discovered in a traffic report later.
Are JavaScript redirects acceptable during a migration?
Only as a last resort. Google says to use JavaScript redirects only if you cannot do server-side or meta refresh redirects, and warns that Google might never see one if rendering of the content failed. For a planned rebuild where you control the server, a server-side permanent redirect is available and is the recommended option.
Related pages in this guide
Related reading
Sources
Every claim on this page that could be checked against a primary source is linked below. Where something is not publicly documented by a vendor, the page says so rather than filling the gap with an estimate.
- Redirects and Google Search (Google Search Central)
- Site move with URL changes (Google Search Central)