You launched the new website.

The old pages were replaced. URLs changed. Maybe the domain changed too.

Then you search for your business in Google and the old pages are still there.

Sometimes they still appear with the old URL. Sometimes Google is showing an old page title or description. In other cases, clicking the result sends you to the new page, but Google still displays the old address.

This can be confusing, especially when the website migration was supposed to be finished.

There are situations where seeing old URLs in Google for a while is completely normal. Google has to recrawl the old URLs, discover the redirects, process the new URLs, and update its index. Google says this process happens on a URL-by-URL basis and that a small or medium-sized site can still take several weeks for most pages to move through its index.

There are also migrations where old URLs remain visible because something was missed.

The important question is whether Google is simply processing the migration or whether the old and new sites are sending conflicting signals.

First, check what happens when you click the old page

Start with the simplest test.

Search Google for one of the old pages and click the result.

Where do you end up?

Ideally, an old page that was replaced during the redesign should redirect directly to the most relevant new page.

For example:

example.com/old-services-page/

should send the visitor to something like:

example.com/services/

if that is where the same content now lives.

Google recommends permanent server-side redirects such as a 301 or 308 when a page has permanently moved. These redirects tell both users and Google that the content now has a new location.

If the old result redirects correctly, seeing the old URL temporarily does not necessarily indicate a problem.

If the old URL still loads the old page, returns an error, redirects somewhere unrelated, or behaves inconsistently, the migration deserves a closer look.

An old URL can still appear even when the redirect is working

This is one of the more confusing parts of a website migration.

A 301 redirect does not immediately erase the old URL from Google’s memory.

Google keeps track of the old address and the new destination. Its current documentation specifically notes that an old URL can sometimes continue appearing in search results even after Google has indexed the new URL.

This is especially common after a domain change. Google describes the old URL as an alternate name for the new canonical URL and says old domain URLs can occasionally continue appearing while its systems process the move.

So there is a big difference between:

Google still displays an old URL, but clicking it correctly reaches the new page

and:

Google still displays an old URL because the migration was never properly communicated to Google.

The first can be part of the transition.

The second can turn into a much larger SEO problem.

Check whether every important old URL has a proper destination

One of the most common migration problems is incomplete redirect mapping.

During a redesign, URLs often change.

You might go from:

/services-web-design.php

to:

/services/web-design/

Or:

/about-us.html

to:

/about/

Or an entire old domain may be replaced with a new one.

Someone needs to decide where each important old URL should go.

Google recommends creating a URL mapping before a migration and redirecting old URLs to their corresponding new locations.

That sounds straightforward until you are dealing with a website that has existed for ten years.

There may be:

• Old service pages
• Blog posts
• Landing pages
• Location pages
• PDFs
• Campaign URLs
• Product pages
• Previous redesign URLs
• Pages that nobody remembers creating

A redesign team may focus heavily on the pages that are currently visible in the website navigation while overlooking URLs that still receive search traffic or backlinks.

Those forgotten pages are often where migration problems begin.

Redirecting everything to the homepage can create problems

Another migration shortcut is sending a large number of old URLs to the new homepage.

For example:

/old-service-a/ → /

/old-service-b/ → /

/old-location-page/ → /

/old-resource/ → /

That may appear cleaner than leaving the URLs broken, but Google specifically advises against redirecting many unrelated old URLs to one irrelevant destination such as the homepage. Google says these redirects can confuse users and may be treated as soft 404s.

The better destination is usually the page that most closely replaces the old content.

If an old service page has a direct replacement, send it there.

If several older pages were intentionally consolidated into one strong new page, they may reasonably redirect to that consolidated destination.

If the content truly has no replacement and is no longer useful, the correct response may be different.

This is why migrations need a URL-by-URL strategy rather than one blanket redirect rule.

Make sure the old pages are actually redirecting

Sometimes everyone involved in a redesign believes redirects were added.

That does not guarantee they are working.

We regularly see issues where:

• Redirect rules were created but never deployed
• Redirects only work for some URL patterns
• HTTP URLs behave differently than HTTPS URLs
• www and non-www versions behave differently
• Trailing slashes create different results
• Redirects depend on a WordPress plugin that was removed
• An old hosting environment was shut down before the redirects were moved
• A domain was pointed somewhere new and the previous redirect configuration disappeared

The quickest way to understand what Google is being told is to test the old URLs directly.

A proper permanent redirect should return a permanent redirect response and lead directly to the intended new URL.

The browser appearing to reach the right page is useful, but it does not always tell you the full story.

There may be multiple redirects happening behind the scenes.

Look for redirect chains

An old URL should ideally reach its final destination directly.

A migration can create chains such as:

Old URL

→ Previous redesign URL

→ Temporary URL

→ Current URL

This often happens when a website has been redesigned multiple times and nobody cleaned up the earlier redirect structure.

Google can follow redirect chains, but they add unnecessary complexity.

They also make troubleshooting harder.

When reviewing a migration, we usually want to know:

• What response does the old URL return?
• Where does it redirect?
• How many steps does it take?
• Does the final page load successfully?
• Is the destination actually relevant?

A long chain can also be a clue that the migration inherited years of technical history that nobody reviewed before launch.

Check the new page’s canonical URL

Redirects are only one signal.

The new pages also tell Google which URL they consider to be the preferred version through canonical tags.

After a migration, the canonical on a new page should generally point to the new URL.

Google specifically recommends checking canonical annotations after a site move to make sure they reference the new URLs.

Problems happen when a migration accidentally leaves something like:

New page canonical → Old page

Now the redirect may be saying:

This content moved to the new URL.

while the canonical is saying:

The old URL is the preferred version.

Those conflicting signals can slow down or confuse Google’s processing of the migration.

This is exactly the kind of issue a business owner would never see by looking at the new website.

The site can look completely finished while its technical SEO signals are still pointing backward.

Check whether the new website still links to old URLs

Internal links matter too.

After a migration, the website’s own links should point directly to the new URLs.

Google recommends updating internal links as part of a site move rather than continuing to send visitors through the old URLs and their redirects.

Imagine the site navigation contains:

/services/new-service-page/

but articles, footer links, buttons, or older content still link to:

/old-service-page/

which then redirects to the new page.

Visitors probably will not notice.

Google sees a website that is still repeatedly referencing the old address.

This can happen when:

• Old links remain in blog posts
• Buttons were copied from the old site
• Global templates still use old URLs
• Hard-coded links were missed
• Old page-builder content was imported
• Menus were rebuilt but body content was not reviewed

A clean migration should update those links directly.

Check the XML sitemap

Your sitemap should also reflect the new website.

After a URL-changing migration, Google recommends submitting the new sitemap through Search Console.

If the sitemap still contains old URLs, you may be telling Google:

These old pages are still part of the current website.

while redirects and other signals say:

These pages moved.

Again, the issue becomes inconsistent information.

Check whether:

• The current sitemap contains only the URLs that should be indexed
• Old URLs were removed
• The new sitemap was submitted in Search Console
• Google can actually access it
• The sitemap uses the correct domain and protocol

A sitemap alone does not force Google to update the index, but it helps Google discover the current URL structure.

Make sure the new pages can actually be indexed

This is a surprisingly common redesign problem.

The migration team correctly redirects an old page to its replacement, but the replacement page cannot be indexed.

That can happen because of:

• A leftover noindex directive
• A canonical pointing somewhere else
• Robots configuration
• Authentication
• Server errors
• Pages only available in staging
• Incorrect redirects
• Technical rendering problems

Google specifically warns site owners to remove temporary noindex rules used during development when launching a migrated site.

A development team may have correctly prevented Google from indexing the staging website while it was being built.

Then the new site launches and nobody removes that restriction.

The website looks fine to users.

Google cannot properly replace the old pages with the new ones.

A redesigned site can accidentally preserve both versions

Another situation is when both the old and new versions remain accessible.

For example:

oldsite.com/service/

still returns a normal page.

Meanwhile:

newsite.com/services/service/

also returns a normal page.

Now Google has two accessible versions of substantially similar content.

This can happen during domain migrations when the previous hosting environment is left online without redirects.

It can also happen within the same domain if the old URL structure remains accessible while the new structure is added alongside it.

That can create a much more confusing situation than an old Google result that simply redirects.

You want a clear relationship between the old location and the new one.

How long should old pages remain in Google?

There is no universal timeline.

Google says that for a small or medium-sized website, most pages in a site move may take a few weeks to process, while larger sites can take longer. Google also notes that the move occurs on a per-URL basis because Googlebot needs to revisit the old and new URLs.

Some pages will change quickly.

Others may linger.

Older pages that Google rarely crawls can take longer because Google has fewer reasons to revisit them.

That is why seeing a few old URLs shortly after launch is very different from seeing a large portion of the old website still appearing months later.

When should you start worrying?

I would be more concerned if:

• Important old pages do not redirect anywhere
• Old and new versions both load normally
• Redirects point to unrelated pages
• Google continues ranking old URLs while the replacements remain absent
• New pages cannot be indexed
• Canonicals still point to the old site
• The sitemap still contains old URLs
• Internal links still heavily reference old pages
• Search traffic dropped at the same time
• Search Console shows widespread indexing or redirect problems
• Several weeks have passed with little sign that Google is processing the move

That is where the issue moves beyond normal migration lag and into something worth auditing.

Search Console can help determine what Google actually sees

Google Search Console is usually one of the first places I would look.

For an individual old URL, URL Inspection can help answer questions such as:

• Does Google know about the URL?
• Has Google crawled it recently?
• Is Google seeing a redirect?
• Which URL does Google consider canonical?
• Is the replacement page indexed?

You can also compare indexing reports and sitemap data to see whether the old URL structure is disappearing and the new structure is taking its place.

The useful question is not simply:

Is the old URL still in Google?

You want to understand:

What does Google currently believe the relationship is between the old URL and the replacement?

That tells you much more about whether the migration is progressing normally.

Do not remove redirects just because the old URLs are still appearing

This is an easy mistake to make.

Someone sees the old URL in Google and assumes the redirect must not be working.

Then they remove it.

That usually makes the migration worse.

Google recommends keeping migration redirects in place for as long as possible, generally at least one year, so that Google has enough time to recrawl the old URLs and transfer signals to the new locations.

For users, keeping useful redirects indefinitely can make sense.

Old URLs may still exist in:

• Bookmarks
• Email campaigns
• PDFs
• Social media posts
• External websites
• Old advertisements
• Printed materials
• Backlinks

A redirect continues helping those visitors reach the correct page long after Google has updated its search results.

The Google Removal Tool usually is not the solution to a migration problem

Seeing an outdated URL in Google can make the Search Console Removals tool seem tempting.

For a normal migration, that usually does not address the underlying issue.

The more important job is making sure Google receives clear permanent signals about where the content moved.

That means:

• Correct redirects
• Correct canonicals
• Updated internal links
• A clean sitemap
• Indexable replacement pages

Trying to hide the old URL without fixing those signals can leave the real migration problem unresolved.

What if the old URL redirects correctly but Google still displays it?

If the redirect is correct, the destination is indexable, the canonical is correct, internal links use the new URL, and the sitemap has been updated, the best answer may simply be to give Google more time.

Google’s current documentation explicitly says that old URLs can occasionally continue appearing as alternate names even after the new URL is indexed.

That is why I would never judge a migration based solely on the text of one Google result.

Look at the full set of signals.

If everything points cleanly to the new page, Google may simply still be processing the change.

What if traffic also dropped after the redesign?

That changes the urgency considerably.

If old URLs are still appearing and organic traffic dropped after the redesign, I would investigate the migration rather than assuming Google just needs more time.

Common areas to review include:

• Missing redirects
• Deleted high-traffic pages
• Changed URL structure
• Lost content
• Internal linking changes
• Canonical errors
• Indexing restrictions
• Metadata changes
• Sitemap problems
• Pages that no longer have an equivalent replacement

We covered that broader scenario in Why Search Traffic Dropped After a Website Redesign.

An old URL continuing to appear may be one visible symptom of a much larger migration issue.

A migration can look successful while still being incomplete

This is probably the most important thing for a business owner to understand.

A redesign can launch successfully from a visual perspective while the migration work behind it is incomplete.

The new site can:

• Look great
• Load correctly
• Have working navigation
• Pass stakeholder review
• Accept form submissions

while Google is still receiving conflicting information from old URLs, redirects, canonicals, sitemaps, and internal links.

Those things are easy to miss because they generally are not visible during a normal website review.

They tend to become noticeable later, when someone searches for the company and realizes Google is still showing pieces of the previous website.

What should you ask the agency or developer who handled the migration?

You do not need to know how to configure redirects yourself.

You should be able to ask reasonable questions about how the migration was handled.

A few useful ones are:

• Was a full URL redirect map created before launch?
• Were our highest-traffic pages included in that map?
• Do old URLs redirect directly to their closest new equivalents?
• Were internal links updated to use the new URLs?
• Were canonical tags updated?
• Was the new XML sitemap submitted to Google Search Console?
• Was the old sitemap removed or updated?
• Were staging noindex settings checked before launch?
• Was Search Console reviewed after the migration?
• Were old URLs tested after launch?

A competent migration process should have answers to those questions.

You are not asking for a technical lecture.

You are trying to establish whether the search-related part of the migration was actually planned and tested.

If you are unsure whether the migration was handled correctly

If old pages are still showing in Google and you are getting vague answers about why, the next step is usually an audit of the old and new URL structures.

That means looking at what Google sees rather than relying only on how the new website appears in a browser.

We would typically review things such as:

• Old versus new URLs
• Redirect behavior
• Canonical tags
• Sitemap contents
• Internal links
• Search Console indexing
• Important pages that disappeared
• Old pages that still receive traffic
• Whether the new pages are actually indexable
• Whether the migration affected rankings or organic traffic

Kismet’s Technical Website Assessment is designed for situations where a website has been redesigned, migrated, inherited, or changed and there are questions about whether the underlying technical setup was handled correctly.

If the migration also caused a measurable search decline, our article on why search traffic drops after a website redesign covers the other areas I would investigate.

Old pages still showing after your website migration?

Seeing a handful of old URLs shortly after a migration can be normal.

Seeing widespread old URLs, missing replacements, broken redirects, or declining search traffic deserves a closer look.

Kismet Creative Co. helps businesses investigate website migrations, redirects, indexing problems, inherited websites, and other technical issues where the current website does not appear to be behaving the way it should.

Request a Technical Assessment