How to Notify Google of a Site Migration
There is considerably less to do here than most people expect. The timing matters more than the actions. The redirects are what actually communicate a move. Everything on this page supports that process rather than starting it, which is worth understanding before anybody relies on a notification instead of a mapping.
Notification Helps, It Does Not Trigger
A well redirected site is found whether anybody is told or not. The redirects themselves are the message, received by anything that arrives at an old address. Notification accelerates that. It does not cause it.
Why the distinction matters commercially. It changes where effort goes.
Somebody who believes notification is the mechanism will treat it as the important task and the mapping as paperwork. That is the wrong way round. It is a common enough belief to be worth correcting at the top of the page, because it changes how a project allocates the days it has.
What actually communicates the move. Each address, individually.
A move is understood address by address rather than as a single announcement about a site. Each old address has to be visited and its redirect received before that particular page is understood to have moved, which is why a large site takes longer than a small one regardless of what anybody was told.
What notification adds. Speed and completeness.
Telling the relevant places brings forward the moment the new addresses are discovered. It also surfaces problems in reporting that would otherwise be found by accident. Both are worth having.
What it cannot do. Compensate.
No notification repairs a bad mapping. A migration with missing redirects and a perfect notification is a migration with missing redirects. The announcement describes a move that has not fully happened. The addresses nobody mapped stay exactly as broken as they were.
What follows. The steps, in order.
Blocks two to five cover what each one achieves. Block six covers what to look at afterwards.
The Change Of Address Step
There is a specific facility for telling the search engine that a site has moved from one domain to another. It is useful, it is narrow, then it does not apply to most migrations.
What it declares. A whole-site move between domains.
It states that everything previously at one domain is now at another. That is a site-level statement rather than a page-level one, which is why it suits a rebrand and nothing else. It says nothing about which page went where, so it never replaces the mapping.
When it does not apply. Most of the time.
A platform change keeping the same domain. A restructure of addresses within a site. A redesign. None of those is a change of address in this sense. Looking for the facility during one of them is a common source of confusion.
Why it is worth using when it does apply. It is unambiguous.
The redirects communicate the same thing, address by address, over time. This says it once, at site level, which supports what the redirects are doing rather than replacing it. On a large site that is a meaningful head start, since the alternative is waiting for thousands of addresses to be revisited individually.
What has to be true first. Block three.
There is a precondition that catches people out at the worst possible moment, which is worth establishing well before launch day.
Where the interface is covered. Elsewhere.
Our Search Console material covers how the tool itself works. This page covers what it is for and whether you need it.
Both Properties Have To Exist
The old site and the new site are separate things in the reporting. Both have to be set up and confirmed as yours before a move can be declared between them.
Why that is a problem in practice. Timing.
The new site frequently does not exist as a confirmed property until shortly before launch. If confirming it requires something only available once the site is live, the sequence gets tight at exactly the wrong moment, with several people waiting on one another during the busiest hours of the project.
The version that goes badly. Discovered on the day.
A team ready to declare the move finds the new property is not confirmed, else that whoever set up the old one has left and nobody has access. Both are entirely ordinary and both cost a day nobody had.
What to establish in advance. Three things.
That the old property exists and somebody currently at the business can reach it. That the new one can be confirmed before launch rather than after. And that the same person can reach both, since a move declared between two properties requires holding both at once.
Why the access question is the sharp one. It is frequently historic.
These properties are often set up years earlier by an agency or a developer who is no longer involved. Establishing who holds access is a task for the planning stage, not for the morning of the launch.
Where it belongs. The checklist.
Alongside the other scoping questions in the site migration SEO checklist.
Submitting The New Sitemap
A sitemap lists the addresses a site has. Submitting the new one after launch is the quickest way for the new addresses to be discovered. It is also the least contentious step on this page.
Why it helps most at launch. Nothing links to the new addresses yet.
Addresses are normally discovered by following links. Immediately after a migration, external links still point at the old addresses, so the new ones are reachable mainly through the redirects. A submitted list is a direct route that skips the wait. It is one of the few things on this page producing a clear benefit for almost no effort.
What it should contain. The site as it now is.
Current addresses only. Addresses that now redirect belong in the old list rather than the new one, because this list describes what exists rather than what used to. Mixing the two produces a list that contradicts the redirects it sits alongside.
When to do it. Once the site is live and correct.
After the launch day checks rather than before them. Submitting a list of addresses while the site is still telling crawlers to stay away achieves nothing at all. It also creates a false sense that the notification work is done.
What it does not do. Guarantee inclusion.
Submitting an address says it exists. It does not require anything to be included. Anybody describing submission as a way of getting pages listed is overstating it.
The old list. A separate decision.
Keeping it available briefly helps old addresses get revisited so their redirects are found, which is covered on the crawling and indexing guide.
Keeping The Old Property
The old site's reporting continues to show useful information during the transition. Closing it, else losing access to it, removes most of the ability to work out what is happening.
What it still shows. The half of the picture nobody else has.
Which old addresses are still being visited, which are returning errors and how the old side of the move is progressing. None of that appears in the new property, because the new property only knows about the new site. The two are not two views of one thing. They are two halves of a picture.
Why the two together are the diagnosis. They answer different questions.
The new property shows whether new addresses are being found. The old one shows whether old addresses are being revisited and redirecting correctly. A problem in the second explains a shortfall in the first.
What closing it early costs. The ability to distinguish.
Without the old side, a shortage of activity on the new site could be a mapping failure, a crawling delay or something unrelated. With both, it is usually obvious which. The difference between those three is the difference between acting today and waiting another fortnight.
How long to keep it. Well past the settling period.
There is no cost to keeping it and a real cost to needing it later. Treat closure as something that happens eventually rather than as part of tidying up after the project.
What To Watch And In What Order
Three things, looked at in this order, because each one explains the next. Watching everything at once produces noise rather than answers.
First, whether new addresses are being found. On the new property.
Whether the addresses that should exist are being discovered and assessed. This is the headline question and it is the one everybody looks at, correctly. It is also the one that answers most slowly, which is why the other two exist.
Second, what the old side is reporting. On the old property.
Errors on old addresses, plus whether they are still being visited. An old address returning an error rather than a redirect is a mapping gap. This is where it appears first.
Third, whether the redirects behave. Directly, not through reporting.
Reporting shows symptoms with a delay. Checking a sample of old addresses by hand shows the cause immediately, which is why it belongs in the sequence rather than being left to a report. It also costs minutes, against days of waiting for something to appear in a dashboard.
Why the order matters. It prevents the wrong conclusion.
New addresses appearing slowly looks like a crawling problem and is frequently a redirect problem. Looking at the old side second is what distinguishes them. Getting that wrong costs weeks of patient waiting for something that was never going to resolve itself.
Where the mechanism sits. Its own cluster.
Our Search Console material covers the reports themselves. What to do with what you find is in monitoring after migration.
Other Places That Need Telling
A search engine is not the only thing holding your old address. Several other places do. The redirects protect all of them while updating them is better.
Business listings and directories. The ones that matter locally.
Anywhere the business is listed with a web address. These are frequently the most valuable references a local business has and they are updated by hand, one at a time. That is why they need to be on somebody's list rather than left to be noticed, since nothing will prompt anybody to remember them.
Social profiles. Quick and usually missed.
Every profile carries a link, seen by people who were already interested. Updating them takes minutes and nobody schedules it.
Email signatures and printed material. The offline half.
Signatures across the business, letterheads, brochures, vehicle livery and anything with a web address on it. Printed items cannot be corrected, which is a reason to keep redirects indefinitely rather than a reason to reprint. A van carrying an old address will be on the road for years after the site moved.
Partners and suppliers. The commercial relationships.
Anybody linking to you as a supplier, a member or a stockist. A short email is usually enough and the link improves as a result. These are also the contacts most likely to act, because there is an existing relationship behind the request.
Advertising destinations. The urgent one.
Any campaign pointing at specific addresses. These cost money per click, so a redirect chain or a broken destination is being paid for on every visit, which makes them the most urgent items on this list rather than the least.
Ask For Important Links To Be Updated
Redirects carry value and a direct link is better. Contacting the sites behind your most valuable links is a small, concrete task that almost nobody does.
Why it is worth doing. Two reasons.
A direct link does not depend on a redirect continuing to exist, which removes a long-term dependency. And it reaches the destination in one step rather than two, which is better for anybody clicking it. Neither reason requires believing anything unprovable about how value moves through a redirect.
Who to contact. A short list, not everybody.
The addresses identified as most valuable during the audit. Trying to contact every site that has ever linked to you is unrealistic and unnecessary. The value is concentrated in a small number of them, which is precisely why the audit produced a priority list rather than a complete one.
What to send. Something easy to act on.
The old address and the new one, plainly, so the recipient can make the change without working anything out. A request requiring somebody to investigate will not be actioned, because the person receiving it has no particular reason to spend time on your migration.
The realistic expectation. Some will, some will not.
Plenty of sites are no longer maintained and plenty of contacts have moved on. A modest success rate on your most valuable links is still worth an afternoon, particularly since the alternative is depending on a redirect for the rest of the site's life.
What this does not replace. The redirects.
They stay regardless, indefinitely, because most links will never be updated. This reduces dependence rather than removing the need. The processing question is in how long Google takes to process a migration. The full series is on the website migration guide.
The redirects
are the
message.
Both properties confirmed and reachable before launch day rather than on it, the new list submitted only once the site is telling crawlers the right thing, the old property kept because it holds half the diagnosis, listings and profiles updated by hand, with the valuable links contacted directly rather than left on a redirect forever.
What a migration engagement covers:
A migration is a one-off project rather than a monthly service, so it is scoped and quoted against the size of the site and how much is changing at once.
Every guide.
One practice.
What a migration is, the types, when to do it, planning, the checklist, auditing, mapping, redirects, internal links, tags, downtime, crawling, structured data, performance, notifying, monitoring, recovery and the mistakes.
