HTML base and SEO: Audit the URL Behind Every Relative Link

For an HTML base href SEO problem, compare the link as written, the document's effective base address and the destination the browser resolves. A relative link can look reasonable in a template while pointing to the wrong page in the rendered document. Changing the anchor text will not repair that address.

Start with a real destination mismatch. Then inspect the mechanism that produced it. The method below uses fictional Alder Docs and reserved example addresses to make the checks concrete. It is a worked example, not a report of testing a live customer site.

Identify which address you are inspecting

A page can have several addresses worth recording: the URL requested, the URL reached after navigation, the base used for relative references and the final destination of a clicked link. Give each field its own name. “The URL” is too ambiguous for a useful bug report.

MDN's base-element reference explains that the base element supplies the base URL for relative URLs in a document. The effective value is available through baseURI; without a base element, it defaults to the document's location.

For a diagnosis, capture the actual rendered value rather than copying the intended setting from a build configuration. A correct configuration file is not evidence that the delivered page used it.

Record the environment too. A production hostname, a preview hostname and a site mounted under a path can expose different mistakes even when they use the same content template.

Make one expected destination explicit

Suppose the fictional page is served at https://example.org/help/start. Its template supplies a base of https://example.org/docs/. A visible “Export guide” link has the written href value export.

In that setup, the relative reference resolves to https://example.org/docs/export. If the intended destination is https://example.org/help/export, the anchor's label can be perfectly accurate while its address is wrong.

Write that difference down before changing anything. The defect is not “relative links are bad.” It is that this link, under this effective base, reaches a destination that does not match the site's intended navigation.

Use the browser's inspected resolved address and the observed navigation as evidence. The example addresses above are explanatory; they are not links you need to visit or pages that are claimed to exist.

Compare the written value with the resolved value

In the browser's inspection tools, distinguish the href attribute text from the link's resolved address. Preserve both in the record. The raw attribute tells you what the template emitted; the resolved address tells you how that reference is interpreted in this document.

Also save the page address and effective base beside them. A screenshot of only the link text cannot show the whole relationship. A screenshot of only the final page can hide which route brought the reader there.

For Alder Docs, a useful row contains the page under test, export as the written reference, the effective docs base, the observed resolved address and the intended help address. The owner can now decide whether the base or the individual reference is wrong.

Repeat the same check on one unaffected link. That comparison can expose whether the defect is broad or limited to a component that was copied from another template.

Treat path forms as different inputs

A document-relative path, a root-relative path and a full absolute address express different intentions. Do not replace them mechanically without checking where the site is deployed and which host should own the destination.

In the fictional example, export follows the docs base path. A reference beginning with /help/export uses the origin of the effective base and supplies its own path. A full https://example.org/help/export address states the destination explicitly.

That does not make the longest form correct in every template. If a preview environment should remain self-contained, hardcoding the production host can create a different navigation problem. If content is deliberately shared across hosts, silently inheriting the current host can also be wrong.

Choose a convention for the actual publishing arrangement. Record the expected behavior on each supported deployment context so a later cleanup cannot erase the reason for the choice.

Check fragment links as well as page links

A table of contents often uses references such as #export. Readers may expect these to move within the page they are reading. With a base URL present, inspect that expectation instead of assuming the fragment is local.

MDN documents that fragment references are resolved against the base too. In a page whose base names another address, a fragment link can therefore target that address with the fragment attached.

For Alder Docs, the acceptance question is simple: does “Export” in the contents lead to the export section in this guide? Record the intended page and section together. A destination that loads successfully but lacks that section still fails the reader's task.

Check the observed navigation without inferring crawler behavior from it. You have established what the browser resolves and what the reader reaches. An engine-specific rendering or indexing conclusion needs its own evidence.

Find the owner of the base value

Trace the effective base to the source that actually controls it. It might belong to the document template, a build setting or a publishing component. Keep the investigation focused on observed output rather than every configuration file that mentions a public URL.

Imagine that Alder Docs copied a docs template into its help center. The old base remained while navigation components were written for the help path. Fixing each broken link separately would leave the shared cause in place.

The opposite case matters too. If the base is intentional and only one copied component assumes a different path, changing the base could disrupt correct navigation elsewhere. The smallest text change is not always the smallest behavioral change.

Assign one owner to the decision and identify the affected templates. An SEO editor can describe the intended destination; the implementation owner can explain which layer should produce it.

Test the repair as a route decision

Use a small representative set: the original failing page link, an unaffected link, a fragment link and a resource or component that relies on the same base. Include a page mounted under the supported nested path if that arrangement is part of the product.

For each item, compare the written reference, resolved address and actual destination with the agreed expectation. Mark a check unresolved when you have not observed it. A source diff alone does not close the navigation defect.

If the repair removes or changes a shared base, look for effects beyond article links. Keep the test list tied to components that actually depend on it. Do not claim that every browser, crawler and rendering system has been verified because a short manual sample passed.

The useful outcome is a bounded statement about the routes inspected, with a date and an owner. That is stronger than a blanket “SEO fixed” label.

Keep discovery claims separate from navigation checks

An internal answer page needs an accurate path from the places that refer to it. Repairing a wrong destination can improve that reading path. It does not prove that Google has indexed the page or that an answer engine will cite it.

For the work record, distinguish what the site emits, what the browser resolves, what the reader reaches and what a search surface later shows. These observations can support each other without being interchangeable.

If a search report still shows the old address after the repair, inspect that as a separate issue. Avoid changing canonicals, redirects and link conventions all at once merely because they all concern URLs. Each change needs a specific reason.

For your next relative-link bug, save the three addresses before choosing a fix. The written reference, effective base and resolved destination make the problem reviewable. A clear expected route then gives both the developer and the content owner a concrete way to say when the work is done.

Hey I'm Uriel Bitton. I write about SEO, AEO, GEO, and helping brands get found in AI answers.

Subscribe for practical ways to grow your brand's visibility in search and AI answers.

Explore HoneyWeRank for SEO and AI visibility.

Sources

MDN: The HTML base element