The live Contact button opens staging.example.com/contact. Staging sits behind a login, so the tab fails. View source still shows that hostname in the href.
The dump from staging copied more than pages. It copied every absolute URL the CMS had written into the database.
This post is how those hosts get baked in, and how to replace them without wrecking serialized options. Staging URLs ranking in Google, covered in why staging site URLs rank above your live domain, is a crawl problem, not this one.
The database copied the staging host into the links
Most editors save a full URL when you insert a link or an image. That string includes the host the editor was using that day.
On staging, that host is staging.example.com. After the dump, production still serves those strings.
Google's site-move guide tells you to change internal links on the new site from the old URLs to the new ones. Redirects from the old host are a backup for other sites. They are slow for your own visitors, and they do nothing if production cannot reach staging.
A relative path in body HTML survives a host change. A stored absolute URL does not. The leak is the host sitting in the row, not the template that prints the menu.
Find every store that saved the hostname
Search the database and the rendered HTML for the staging host, not only the theme files. Theme links that use a site-url helper will flip when the environment setting flips. Content blobs will not.
Content, menus, and media
Post HTML, widgets, and menu custom links are the usual pile. Image sources and file downloads get the same treatment when the media library stores a full URL. A page can look live while every button still names staging.
Google can crawl a relative href. It cannot follow a host that no longer resolves, or one that still resolves to a gated copy.
The href still has to resolve to a real web address. A leftover staging URL fails that bar on the live domain.
Canonicals, sitemaps, and redirects
Google's canonical documentation recommends absolute URLs in the rel-canonical link. Relative canonicals can later resolve against the wrong host, including a testing site that was never meant to be crawled. That is why the tag should be absolute, and why it must be built from the live site URL at request time.
If those absolute tags were saved into the database on staging, production HTML still advertises staging as the preferred URL. Redirects that map old paths to staging paths have the same bug. They send Google and people off the property you just launched.
Google's move troubleshooting calls out redirects that land on missing URLs, and a spike of not-found errors in Search Console. Staging hosts in your own hrefs produce that same report on a site that otherwise looks launched.
Replace hosts without breaking serialized strings
Many CMS options and widget settings are stored as serialized PHP or as JSON with a length prefix. A plain find-and-replace of a long staging host with a shorter live host leaves a count that no longer matches the string. The option then fails to load, and the menu disappears.
Use a replace that understands that format, or export, rewrite, and write the value back through the CMS. Do not open a dump in a text editor and swap the domain. That is how Contact comes back while the footer widgets die.
Keep one source of truth for the public host. Environment config or the CMS site URL should mint canonicals, sitemaps, and new editor links.
Old rows still need a one-time rewrite. New rows should not bake a hostname that changes between environments.
After the rewrite, regenerate sitemaps so they list live absolute URLs. Google crawls sitemap entries exactly as written. A sitemap that still lists staging is a map to the wrong site.
Check both the www and non-www hosts, and http versus https, if staging used a different pair than production. A replace that only looks for staging.example.com will miss https://www.staging.example.com in older posts.
Prove the live HTML no longer names staging
View source on Contact, a blog post with in-body links, and a page that uses a featured image. Search that HTML for the old host. A green homepage is not the test.
Also search rendered email templates and XML feeds if the CMS stores those in the same tables. A post can look fixed in the browser while the RSS item still points at staging.
- Search the database for the staging hostname in posts, menus, options, and media.
- Rewrite those values with a serializer-aware replace, not a plain text swap.
- Point the CMS site URL at the live host so new links do not bake staging again.
- Regenerate sitemaps and confirm canonical tags use the live absolute URL.
- View source on key templates and search the HTML for the old hostname.
- Fix any redirect rules that still send paths to the staging host.
If Preview or a crawl still finds staging in href or canonical, the dump is not finished. Leave a redirect from staging only as a safety net for other websites, not as the way your own header works.
Unlike a full web development and martech build, this post covers only hostnames baked into the database after a staging copy. For a look at whether live pages still link at the old host, start with Get Free Assessment.
If this post is wrong, outdated, or you would take a different path
I write from work I have done on real sites. Search products change, and a step that was right when I published can go stale. I can also be wrong about the method.
If you disagree with the approach, the facts, or the outcome, I want the detail. Tell me what is off, what you would do instead, and where you saw it. I use that to correct the post so the next reader is not stuck.
This is not a comment thread. Use Contact me so the note is tied to this post and I can reply.
You are sending feedback for
Why your staging site migration broke internal links
Web Development & Martech
https://test.hammadshk.com/blog/why-your-staging-site-migration-broke-internal-links
