URLs & Web Fundamentals
What is a relative URL?
A relative URL is a web address that omits some or all of the scheme and authority components, relying on context to supply the missing parts and resolve to a complete absolute URL. Where an absolute URL like https://example.com/products/blue-widget is fully self-contained, specifying everything needed to locate the resource, a relative URL like /products/blue-widget is incomplete on its own. It must be interpreted in relation to a base URL, typically the URL of the page containing the relative URL, to resolve to the full absolute address.
The word relative captures the essential characteristic, the URL’s meaning is relative to something else. /products/blue-widget means different things on different domains, on https://example.com it resolves to https://example.com/products/blue-widget, on https://other-site.com it resolves to https://other-site.com/products/blue-widget. The same relative URL string represents different absolute resources depending on its context.
Relative URLs are primarily used within HTML documents for internal navigation, links from one page to another on the same site, image sources, stylesheet references, and script sources. In these internal contexts relative URLs provide a practical advantage over absolute URLs, they do not include the domain, so if the domain changes the internal links continue to work without updates. This portability makes relative URLs the natural choice for internal references within a site.
However relative URLs are explicitly inappropriate for contexts where the absolute canonical URL must be specified unambiguously, canonical tags, XML sitemaps, HTTP Location headers in redirect responses, and cross-domain references all require absolute URLs. Understanding precisely when relative URLs are appropriate and when absolute URLs are required prevents common technical SEO mistakes.
Types of relative URLs
Relative URLs come in three distinct forms, each omitting different components of the full absolute URL and resolving differently based on context.
Root-relative URLs: the most widely used relative URL form. Root-relative URLs begin with a forward slash, /: and specify the path from the domain root. /products/blue-widget is a root-relative URL. Regardless of which page on the site contains this URL it always resolves to the same path on the same domain, the browser takes the current page’s scheme and authority, https://example.com: and appends the root-relative path, /products/blue-widget: to form https://example.com/products/blue-widget.
Root-relative URLs are predictable and portable within a site. They resolve consistently regardless of where the page containing them is located in the site’s path structure. A root-relative link to /products/blue-widget on a page at /blog/post resolves the same way as the same link on a page at /category/subcategory/page: both resolve to https://example.com/products/blue-widget. This consistency makes root-relative URLs the recommended form for internal links in HTML.
Document-relative URLs: relative URLs that omit the leading slash and are resolved relative to the current document’s location. products/blue-widget: without a leading slash, is a document-relative URL. Its resolution depends on the path of the current document.
On a page at /blog/ the document-relative URL products/blue-widget resolves to /blog/products/blue-widget. On a page at / it resolves to /products/blue-widget. On a page at /section/category/ it resolves to /section/category/products/blue-widget. The resolution changes with the current page’s location, making document-relative URLs unpredictable when content is reorganised or templates are reused across different path levels.
Document-relative URLs are useful in specific controlled contexts, particularly in documentation systems and file servers where path relationships between documents are stable and well-defined. For general web application internal linking they are error-prone and generally avoided in favour of root-relative URLs.
Path traversal with ../: document-relative URLs can use ../ to navigate up directory levels. ../products/blue-widget from a page at /blog/post resolves to /products/blue-widget: the ../ moves up one level from /blog/ to /. Multiple ../ segments move up multiple levels. These traversal sequences work correctly when the directory structure is stable but become unreliable when pages are moved between directories.
Protocol-relative URLs: also called scheme-relative URLs, omit the scheme but include the authority and path. //example.com/products/blue-widget is a protocol-relative URL. It resolves by inheriting the scheme from the current page, https: on an HTTPS page, http: on an HTTP page.
Protocol-relative URLs were introduced to handle resources that needed to work over both HTTP and HTTPS, a stylesheet at //cdn.example.com/styles.css would load over HTTPS on HTTPS pages and HTTP on HTTP pages. This was useful during the transition period when sites served both HTTP and HTTPS content.
With HTTPS now the universal standard for web content protocol-relative URLs offer no advantage over absolute HTTPS URLs. On a fully HTTPS site a protocol-relative URL and an absolute HTTPS URL behave identically. Protocol-relative URLs are increasingly considered a legacy pattern, absolute HTTPS URLs are preferred.
How relative URLs are resolved
The resolution process, converting a relative URL to an absolute URL, follows defined rules specified in RFC 3986. Understanding the resolution algorithm clarifies how browsers and other clients interpret relative URLs.
The base URL: every relative URL resolution requires a base URL, the reference point from which the missing components are supplied. In HTML the base URL is typically the URL of the page containing the relative URL, the page’s own absolute URL. The HTML <base> element can explicitly specify a different base URL, any relative URL on the page is resolved against the declared base URL rather than the page’s URL.
For root-relative URLs the base URL supplies only the scheme and authority, the path from the relative URL replaces the base URL’s path entirely. For document-relative URLs the base URL’s path, up to the last /: is the starting point for resolution. The relative path is appended to this base path with path traversal sequences, ../: applied.
Resolution examples: tracing resolution for each relative URL type illustrates the process.
Base URL, https://example.com/blog/post-title
Root-relative /products/blue-widget resolves to https://example.com/products/blue-widget: scheme and authority from base, path replaced entirely.
Document-relative ../products/blue-widget resolves to https://example.com/products/blue-widget: ../ moves up one level from /blog/ to /, then appends products/blue-widget.
Document-relative widgets/blue-widget resolves to https://example.com/blog/widgets/blue-widget: appended to the base path’s directory /blog/.
Protocol-relative //cdn.example.com/styles.css resolves to https://cdn.example.com/styles.css: scheme https: inherited from base.
Relative URLs in HTML
HTML documents use relative URLs extensively, for internal navigation, resource loading, and cross-references within a site.
Anchor links: internal navigation links in HTML are the primary use case for relative URLs:
Root-relative internal links are preferred, they resolve consistently regardless of the current page’s path location. Document-relative links are appropriate in controlled environments where path relationships are stable.
Image sources: image src attributes in HTML use relative URLs for images within the site:
Root-relative image URLs ensure images load correctly regardless of which page embeds them. Images hosted on external CDNs use absolute URLs, https://cdn.example.com/images/blue-widget.jpg.
Stylesheet and script references: <link> and <script> elements load resources using relative or absolute URLs:
Internal resources, stylesheets, scripts, fonts hosted on the same domain, use root-relative URLs. External resources use absolute URLs.
The <base> element: the HTML <base> element sets the base URL for all relative URLs on a page:
With a <base> element all relative URLs on the page resolve against the declared base URL rather than the page’s own URL. The <base> element affects all relative URLs on the page, including anchor links, image sources, and form actions. Use carefully, unexpected <base> declarations cause relative URL resolution errors that can be difficult to debug.
Relative URLs and SEO
Relative URLs interact with several SEO mechanisms, primarily through their resolution behaviour and the implications for canonical URL specification.
Relative URLs in canonical tags, avoid: the most significant SEO concern about relative URLs. Canonical tags should always use absolute HTTPS URLs, not relative URLs. A canonical tag with a relative URL:
Is technically valid but creates protocol ambiguity. If the page is accessible at both http://example.com/page and https://example.com/page the relative canonical resolves to the HTTP version on the HTTP page variant, incorrectly specifying the non-HTTPS canonical. The absolute canonical:
Is unambiguous regardless of how the page is accessed, always specifying the canonical HTTPS URL.
Relative internal links and redirect overhead: internal links using relative URLs that resolve to non-canonical absolute URLs add unnecessary redirect hops. A root-relative link /page on an HTTP page resolves to http://example.com/page: requiring an HTTP-to-HTTPS redirect before reaching the HTTPS canonical. For sites enforcing HTTPS through server redirects this is a minor inefficiency, each internal navigation triggers a redirect hop before reaching content.
Using absolute HTTPS URLs, or ensuring root-relative URLs resolve to canonical HTTPS URLs through the page’s HTTPS context, eliminates this overhead. For sites consistently served over HTTPS all root-relative URLs resolve to HTTPS absolute URLs, no redirect overhead.
Relative URLs and crawl budget: when search engine crawlers follow relative internal links they resolve the links and crawl the resulting absolute URLs. Relative links that resolve to non-canonical URLs, HTTP variants, non-www variants, cause crawlers to encounter redirect responses before reaching canonical content. While crawlers follow these redirects the redirect hops consume crawl budget. Absolute HTTPS canonical URLs in internal links eliminate the redirect hops, the crawler reaches canonical content directly.
Hreflang annotations require absolute URLs: hreflang link annotations for international sites must use absolute URLs:
Relative URLs in hreflang annotations create resolution ambiguity when pages are accessed from different URL variants, the relative URL resolves differently depending on the access URL. Absolute URLs in hreflang annotations specify the language variant URLs unambiguously.
Relative URLs and redirect management
Relative URLs interact with redirect management in specific ways, primarily in ensuring redirect destinations are specified correctly and that internal links do not create unnecessary redirect dependencies.
Redirect destinations must be absolute URLs: redirect rule configurations should always use absolute URLs for destination specifications. A redirect destination of /new-page is ambiguous in a redirect management context, it may be interpreted as a root-relative path on the source domain, creating an incorrect same-domain redirect when a cross-domain redirect was intended. Absolute HTTPS URLs, https://example.com/new-page: are unambiguous redirect destinations.
HTTP Location header absolute URLs: HTTP redirect responses include a Location header specifying the redirect destination. While the HTTP specification permits relative Location header values, resolved relative to the request URI, best practice is absolute URLs in Location headers. Some HTTP clients, particularly non-browser HTTP clients and API consumers, may not correctly resolve relative Location header values. Absolute Location header URLs ensure correct redirect behaviour across all client types.
Updating internal relative URLs after domain migration: after a domain migration internal root-relative links continue to work, they resolve relative to the new domain without modification. However if any internal links use absolute URLs with the old domain those must be updated to the new domain. A content audit for absolute internal URLs after domain migration identifies links that need updating from old domain absolute URLs to new domain absolute URLs, or to root-relative URLs that resolve correctly on the new domain.
Protocol-relative internal resources and HTTPS migration: during HTTP to HTTPS migration protocol-relative URLs for external resources, //cdn.example.com/resource: automatically upgrade to HTTPS on HTTPS pages, eliminating mixed content warnings for those resources. This is one of the few remaining advantages of protocol-relative URLs, they can ease HTTPS migration for externally hosted resources that support HTTPS.
Common relative URL mistakes
Document-relative URLs in templates: using document-relative URLs in CMS templates or shared components that are reused across pages at different path depths. A document-relative link products/blue-widget works correctly on pages at the root level but resolves incorrectly on pages in subdirectories. Replace document-relative links with root-relative links in templates, /products/blue-widget works correctly regardless of the template’s deployment location.
Relative URLs in canonical tags: using root-relative or other relative forms in canonical tags rather than absolute HTTPS URLs. Technically valid but creates protocol ambiguity. Always use absolute HTTPS URLs in canonical tags.
Relative URLs in XML sitemaps: the sitemap specification requires absolute URLs, relative URLs in sitemaps violate the specification and may cause sitemap parsing errors or incorrect URL resolution.
Protocol-relative URLs on HTTPS sites: using protocol-relative URLs, //cdn.example.com/resource: for resources on sites that are fully HTTPS. Protocol-relative URLs offer no advantage over absolute HTTPS URLs on fully HTTPS sites and add subtle risk, if the page is ever accessed over HTTP, perhaps during testing, protocol-relative resources load over HTTP creating mixed content issues. Prefer absolute HTTPS URLs for resources on fully HTTPS sites.
Forgetting the leading slash in root-relative URLs: writing products/blue-widget: a document-relative URL, when / products/blue-widget: a root-relative URL, was intended. The missing leading slash changes the resolution entirely, the document-relative version resolves relative to the current page’s path rather than from the domain root. Always include the leading slash for root-relative URLs.