A Canonical Tag Pointing to Your Dev Site: How to Catch It

A canonical tag tells Google which address is the "real" version of a page. It's one of the strongest signals you can send. So when a canonical tag points to your development site, like dev.example.com, you're telling Google your live page is a duplicate of a site that shouldn't be indexed at all.

How a dev canonical tag gets onto a live page

It's usually a copy-and-paste accident. A page is built and tested on a development copy of the site, where the canonical correctly says https://dev.example.com/pricing.html. The page is copied to the live site, the content is checked, and the head section isn't. The same happens with og:url and schema @id values.

It's easy to miss because the page looks perfect. Nothing on screen shows the canonical tag.

Why a dev canonical tag is harmful

• Google may drop the live page in favour of the address you named, which is often blocked, password-protected or missing.
• Link value is pointed away from your real page.
• Your dev site may get indexed, exposing unfinished work.

Old copies are the hidden source

The live page is often fine; the problem is a second, older copy still being served somewhere else. On our own site, the pricing page was correct, but an old June copy sat in a second folder that the server could also serve at another address. That copy still declared dev.aiwebpageseo.com as its canonical, in 6 places. Nothing linked to it, but it was reachable, and Google can find reachable pages.

How to catch dev canonicals

1. Search your files for dev addresses

Search every page for "dev.", "staging.", "localhost", or your dev domain. Tutorial pages may mention localhost as example code, which is fine; canonicals, og:url and schema values should never contain these.

2. Check what's actually served

Fetch the live page and read its canonical: curl -s https://example.com/pricing.html | grep canonical. What's served is what matters, not what you think is on disk.

3. Check every address that serves the same page

If your server has fallback folders or proxies, the same file name may be reachable under a second path. Request each one.

4. Check nothing links to old copies before removing them

If nothing links to the old copy, move it out of the public folder and confirm the address returns 404.

Canonical rules worth checking at the same time

• The canonical should be the final address, not one that redirects. A canonical pointing to a URL that 301-redirects elsewhere sends mixed signals.
• The canonical should match your sitemap entry for that page.
• Every copy of the address should agree: canonical, og:url and schema @id.
• The tag must be well-formed. A missing closing quote on the tag above it can swallow the canonical entirely, so the browser never sees it.

Preventing it

Build pages with the domain as a setting, not typed in, so copies automatically use the right address. And add a check to your deploy routine: fail the deploy if any live file contains your dev domain in a canonical, og:url or @id.

Summary

A dev canonical on a live page tells Google your real page is a copy of your dev site. Search your files and your served pages for dev addresses, check every path that can serve a page, and remove old copies nobody links to. Our Meta Tag Analyzer shows a page's canonical and og:url exactly as served.

Frequently asked questions

How does a dev canonical tag end up on a live website?

It is usually a copy-and-paste accident. A page is built and tested on a development copy of the site, where the canonical tag correctly points to the dev address, such as dev.example.com. The page is then copied to the live site, the visible content is checked, but the head section is not. The same thing happens with og:url and schema @id values. It is easy to miss because the page looks perfect and nothing on screen shows the canonical tag. Often the live page itself is fine and the problem sits in an older copy still being served from a second folder at another address.

Why is a canonical tag pointing to a staging site harmful for SEO?

A canonical tag is one of the strongest signals you can send Google about which address is the real version of a page. If it points to a development or staging site, you are telling Google your live page is a duplicate of a site that should not be indexed at all. Google may drop the live page in favour of the address you named, which is often blocked, password-protected or missing. Link value is pointed away from your real page. Your dev site may also get indexed, exposing unfinished work to searchers.

What should I check alongside the canonical tag on a page?

The canonical should be the final address, not one that redirects, because a canonical pointing to a URL that 301-redirects elsewhere sends mixed signals. It should match the sitemap entry for that page. Every copy of the address on the page should agree, meaning the canonical, og:url and schema @id. The tag must also be well-formed: a missing closing quote on the tag above it can swallow the canonical entirely, so the browser never sees it. To prevent dev addresses creeping in, build pages with the domain as a setting rather than typed in, and fail any deploy where a live file contains the dev domain.