Element Code: IN-055
<base href> tag in your page's HTML points to a different domain, subdomain, or path than the page it lives on, so every relative link, image, and script on that page silently resolves against the wrong location.What "Mismatched Base URL" Actually Means
The <base> element is an old, easy to forget piece of HTML that goes in the <head> of a document. It sets the base URI that the browser uses to resolve every relative URL on the page: links, images, stylesheets, canonical tags if they are written relatively, form actions, all of it. When there is no <base> tag, the browser just uses the page's own URL as the base, which is what you want almost all of the time.
A mismatch happens when someone sets <base href="https://staging.example.com/"> or <base href="https://example.com/old-section/"> on a page that does not actually live at that address. I see this constantly after a staging-to-production push where a templating variable did not get swapped, or after a domain migration where a base tag was hardcoded to the old domain and nobody touched it again. It also shows up on multi-region sites where a shared header template sets a base href for one locale and every other locale inherits it by accident.
The tag itself is invisible on the rendered page. Nothing looks broken to a human skimming the site. That is exactly why it survives in production for months: QA clicks around, everything appears to work because the person testing is usually on the correct domain already, or the links happen to still resolve somewhere valid. Then a crawler or a user on a different path hits it and every relative asset breaks.
Why This Wrecks Crawling and Indexing
Search engine crawlers parse the DOM the same way a browser does, including the base tag. If your canonical tag, hreflang alternates, or internal links are written as relative paths (a common practice to keep templates portable across environments), a bad base href rewrites all of them against the wrong root. That means:
- Relative canonical tags can resolve to a URL on a different domain entirely, which Google will read as a cross-domain canonical, sometimes ignored, sometimes honored in a way you did not intend.
- Internal links that look fine in the raw HTML actually point crawlers off-site or to a stale subdomain, wasting crawl budget and diluting the link equity you meant to pass internally.
- Images and scripts referenced relatively fail to load for the crawler's renderer, which can affect how Googlebot evaluates page content during the rendering pass, particularly for JS-dependent pages.
- Structured data that references relative image or logo URLs (common in Organization or Article schema) resolves against the wrong base, so rich result eligibility can quietly drop.
The nasty part is that this is not a "some links are broken" bug you catch from a 404 spike. It is a resolution bug. The URLs are technically valid, they just point at the wrong place, so your normal broken-link monitoring often will not flag it. You usually catch it because organic traffic to a template-wide section drops, or because Search Console starts reporting canonical URLs you do not recognize.
How the Browser Resolves It, Visually
How to Detect It
This is one of the few technical issues that is trivial to confirm once you know to look, and painful to find if you do not.
- View source, not DevTools Elements. Check the raw HTML for a
<base>tag in the head. DevTools shows you the resolved DOM, which can mask the problem because the browser has already applied it. - Screaming Frog: run a crawl and check the custom extraction or the "Base" column if you configure an XPath extraction for
//base/@href. Compare it against the crawled URL. Any crawl-wide mismatch shows up instantly across every template that shares the header. - Search Console: the URL Inspection tool shows the "Google-selected canonical" versus your declared canonical. If you see canonicals pointing at a domain or subdomain you do not expect, a base href problem is one of the first things to rule out.
- Server logs: look for Googlebot requests hitting a staging subdomain or an old path structure it should have no reason to know about. That is often the fingerprint of a base tag sending the crawler somewhere it followed a relative link into.
- Sitebulb: its "Base" audit specifically flags pages with a base tag present and will tell you if it differs from the page URL's own origin.
| Symptom | Likely Cause | Where to Check |
|---|---|---|
| Googlebot crawling a staging subdomain | Base href hardcoded to staging in a shared template | Server logs, robots.txt hits |
| Canonical URL in GSC does not match declared canonical | Relative canonical resolved against wrong base | URL Inspection tool |
| Images missing in rich result preview | Relative image path in schema resolved off base domain | Rich Results Test |
| Internal link equity not flowing as expected | Relative nav links resolving to old path structure | Screaming Frog internal links report |
| 404 spike on an old subdirectory that should be dead | Base tag still pointing at the retired path | Log files, GSC coverage report |
How to Fix It
- Find every base tag in your templates. Grep your codebase for
<baseacross layout files, partials, and any environment config that injects it. Most sites only need one, if any. - Decide if you need the tag at all. Most sites do not. If your relative links already resolve correctly without it, delete it rather than trying to fix its value. Fewer moving parts, fewer future mismatches.
- If you do need it, template it correctly. The href should be generated dynamically from the current environment and request host, never hardcoded to a string like "https://staging.example.com" that gets copy-pasted into production config.
- Convert critical relative URLs to absolute. Canonical tags, hreflang alternates, and og:image should be absolute URLs regardless of whether a base tag exists. That removes an entire class of resolution bugs and is a best practice independent of this issue.
- Re-crawl after the fix. Run Screaming Frog again and confirm the base tag is gone or correct on every template, not just the homepage. Shared headers mean the fix should propagate everywhere, but templating logic sometimes has exceptions for legacy page types.
- Watch Search Console for a week. Confirm Google-selected canonicals settle back to your declared ones and that log file crawls stop hitting the wrong host.
What Good Looks Like
No base tag unless there is a specific, documented reason for one. Canonical, hreflang, and social meta tags written as absolute URLs. Internal links can stay relative for maintainability, but they resolve against the actual page URL because nothing is overriding that behavior. A crawl of the site shows one consistent origin for every URL, with zero requests bleeding into a staging or legacy domain.
- Grep templates for every instance of a base tag before assuming there is only one
- Use absolute URLs for canonical, hreflang, and schema image references
- Template the base href dynamically if you must keep one
- Re-crawl after deployment to confirm the fix propagated site-wide
- Hardcode a base href string that gets copied unchanged from staging to prod
- Assume a visual QA pass will catch this, since nothing looks broken on screen
- Leave a base tag in place "just in case" once you confirm it is not needed
- Rely only on DevTools Elements panel, since it shows resolved URLs, not raw source
FAQ
Does every site need a base tag?
Can this cause a duplicate content penalty?
Will fixing the base tag change my URLs?
Why didn't my QA process catch this before launch?
Is this the same issue as canonical tag errors?
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
