An absolute URL is the full address of a resource: protocol, host and path, for example https://www.visilay.com/blog/urls/. A relative URL contains only part of that address, for example /blog/urls/, and the browser fills in the rest using the address of the page it sits on.
For internal links Google treats the two the same way, and it has said so more than once. There are, however, at least five places on a site where you don't get a choice: the canonical tag, the XML sitemap, hreflang annotations, the Sitemap line in robots.txt and the Open Graph meta tags all want the full address. Below you'll find the difference explained with an example, a list of those five places with the official source for each, and the numbers from a check we ran on the 3,729 internal links in our Italian blog.
The difference in one example
The quickest way to understand a relative URL is to see how it gets resolved. Take https://www.visilay.com/blog/urls/ as the starting page and write the same kind of link in six different ways. The table shows the address the browser (and Googlebot) rebuilds in each case.
| How the href is written | Type | Resolved address |
|---|---|---|
https://www.visilay.com/blog/sitemap/ | Absolute | https://www.visilay.com/blog/sitemap/ |
//www.visilay.com/blog/sitemap/ | Protocol-relative | Inherits http or https from the starting page |
/blog/sitemap/ | Root-relative | https://www.visilay.com/blog/sitemap/ |
sitemap/ | Folder-relative | https://www.visilay.com/blog/urls/sitemap/ |
../sitemap/ | Relative, one level up | https://www.visilay.com/blog/sitemap/ |
#faq | Fragment only | https://www.visilay.com/blog/urls/#faq |
The fourth row is the one that causes trouble in practice. Without the leading slash the path starts from the current folder, so the same link placed in a template used at different depths leads to different addresses, often ones that don't exist. That's how chains of 404 errors appear that you only find with a crawler, and in the worst cases crawl traps where paths keep getting longer (/blog/urls/sitemap/sitemap/...).
The other relative forms, written correctly, lead to the same address as the absolute one. All of this rests on one assumption: that the starting page can be reached at a single address. If the same content also answers on http:// or without www, every relative link multiplies that version. We'll come back to this further down, because it's the only case where the choice really matters.
What Google says about internal links
Google Search Central's documentation on crawlable links (updated December 2025) lists both <a href="https://example.com/stuff"> and <a href="/products"> among the correct examples. The requirement is that the href resolves to a real web address that the crawler can send a request to. What Google advises against are hrefs using the javascript: protocol, which don't lead anywhere.
John Mueller, Search Advocate at Google, went into detail during the office-hours session of 26 November 2019 (at 31:33): if the site structure is clean, use whichever form is easier to manage; if the site answers on several host or protocol variants, it's better to work with absolute URLs and make sure they point to the canonical versions. On Google UK the top results for this search split along the same line. Equinet Media tells you to make absolute URLs a site-wide policy, while Concom Web Design says modern search engines handle relative links well and keeps absolute URLs for large, complex sites. Both are right, because they're talking about different sites.
The practical upshot: for links in the body of a page, the format isn't a ranking factor. What counts is how many versions of the site return a 200.
The five places where a relative URL isn't allowed
Here the debate ends, because the specifications spell it out. On 10 October 2026 we read the pages in Google UK's top ten for "absolute url vs relative url" (GeeksforGeeks, Equinet Media, Morten Rand-Hendriksen's blog, Concom Web Design) and none of them gives the full list, so we rebuilt it from the primary sources, with the last update date of each.
| Where | Relative URL accepted? | What the source says | Source (last updated) |
|---|---|---|---|
| Canonical tag in the HTML | Not recommended | Use absolute paths rather than relative paths with the link rel=canonical element | Google Search Central (July 2026) |
| Canonical in the HTTP header | Not recommended | As with the tag, use absolute URLs in the header too | Google Search Central (July 2026) |
XML sitemap, <loc> field | No | Fully qualified, absolute URLs; the sitemaps.org protocol requires every URL to begin with the protocol | Google Search Central (July 2026), sitemaps.org |
| hreflang annotations | No | Alternate URLs must be fully qualified, including http or https | Google Search Central (September 2026) |
| Sitemap: line in robots.txt | No | Must be a fully qualified URL, with protocol and host | Google Search Central (August 2026) |
| og:url and og:image meta tags | In practice, no | The specification doesn't say so explicitly, but every example uses full addresses and og:url is the object's permanent ID | Open Graph protocol |
| Allow and Disallow rules in robots.txt | Yes, it's actually the rule | The path is relative to the root of the site the file was fetched from | Google Search Central (August 2026) |
The last row is there to stop the opposite mistake: in robots.txt the Allow and Disallow directives are written as paths (/wp-admin/), not as full URLs. Only the Sitemap line wants the whole address.
Google is firm on the canonical because a relative canonical leaves the crawler to rebuild the host, which is exactly the information the canonical is supposed to pin down. Sitebulb, in the page for its Canonical is a relative URL hint, reports that Google considers it one of the most common canonical mistakes. For the XML sitemap the rule is stricter still: Google says it will try to crawl the URLs exactly as they're written, within the limit of 50,000 URLs or 50 MB uncompressed per file.
How common the canonical is, for scale
The SEO chapter of HTTP Archive's Web Almanac 2025, based on the July 2025 crawl of 16,213,084 sites, finds a canonical on 68% of desktop pages and 67% of mobile pages, up from 65% in 2024. Only 0.58% of desktop pages declare it in the HTTP header. It's a worldwide sample: there's no equivalent public figure for UK sites alone. Still, it tells you that two pages in three have a field where a relative URL is explicitly discouraged.
When a relative internal link becomes a problem
Outside the five places in the table, a relative URL causes trouble in four recurring situations. None of them is about rankings as such: they're about addresses that multiply or stop working.
The site answers on more than one version
If http://example.co.uk/page/ and https://www.example.co.uk/page/ both return a 200, a crawler that comes in through the wrong version finds relative links that keep it there, page after page. With absolute links every click takes it back to the right version. The real fix sits upstream, though: 301 redirects from every variant to a single one and an SSL certificate active across the whole domain.
We checked this on visilay.com. https://visilay.com/..., http://www.visilay.com/... and the version without the trailing slash answer with a single 301 to the canonical address. http://visilay.com/..., on the other hand, takes two hops: first to https without www, then to the www version. It works, but it's an extra hop worth removing, and it's the kind of detail an SEO audit should bring to light.
Indexable staging and test environments
With relative links a staging site copied from production works without any changes, which is why developers like them. But if Google can reach the staging site, relative links turn it into a complete, navigable duplicate. With absolute links the crawler would be sent back to production on the first click. The answer is still to put staging behind a password, not to change the link format.
Scrapers, feeds and copied content
When a scraper site copies an article, absolute links keep pointing to the original site and carry an attribution signal with them. Relative links, outside their own domain, break or point to the site that copied them. The same goes for RSS feeds, newsletters and text pasted into other tools: wherever the context changes, the full address is the only one that survives.
The base tag
The <base> element changes the starting address for every relative URL on the page. Mozilla's MDN documentation points out a side effect many people don't know about: fragment links are resolved against the base too, so <a href="#anchor"> with a base set to https://example.com/ doesn't scroll the page but opens https://example.com/#anchor. A wrong base in a template breaks every relative link on the site in one go.
What we found in the 3,729 internal links of the Visilay blog
To get first-hand data we pulled from our WordPress database every link in the 263 Italian-language articles published on our blog at the end of September 2026, leaving out empty drafts. The result:
| Item | Value |
|---|---|
| Articles analysed | 263 |
| Internal links to visilay.com | 3,729 |
| Internal links in absolute form | 3,729 (100%) |
| Root- or folder-relative internal links | 0 |
| Internal links using http instead of https | 0 |
| Internal links without www | 0 |
Href javascript:void(0); | 28, spread across 22 articles |
| Internal links with a path missing the language prefix | 1 (/services/seo/) |
| Links to other domains (including mailto and tel) | 1,547 |
The 100% absolute figure isn't an editorial choice on our part: when you pick an internal page from the link search in the WordPress block editor, it inserts the full permalink. Anyone working on WordPress therefore starts from the position Google recommends when in doubt. The problems the check turned up were different ones: 28 javascript: hrefs, which is exactly the form Google's documentation describes as not resolvable, and one link to a path without /it/ that sent Italian readers to the English version of the service page instead of the Italian one. An absolute URL guarantees the right host and protocol; it doesn't guarantee the right path.
One last detail: the HTML the site serves does contain relative links, even though none exist in the database. Cloudflare adds them when it obfuscates email addresses (/cdn-cgi/l/email-protection#...). Checking the CMS source isn't enough: you need to check the page as the crawler receives it.
How to choose for your site
You can make the decision with four checks, in this order.
- Open the four variants of your homepage (
http://,https://, with and withoutwww): if all but one return a 301 in a single hop to the same version, you can use whatever form your CMS generates for links in the body of your pages. - If even one variant returns a 200, fix the redirects first. In the meantime, absolute internal links limit the damage.
- Canonical, sitemap, hreflang, the Sitemap line in robots.txt and Open Graph always take the absolute form, whatever you decide for everything else.
- Ban folder-relative links (no leading slash) in shared templates: they're the only form whose meaning changes depending on the page they appear on.
For the hands-on check, view the source of a page and search for rel="canonical" and hreflang, or run a crawler: Sitebulb flags relative canonicals with a dedicated hint. In Google Search Console the URL Inspection tool shows which canonical Google actually chose, which doesn't always match the one you declared. If the site is multilingual, the checks on hreflang and international SEO are where a relative URL does the most damage, because one mistake repeats on every language pair. More generally, these are checks that belong to basic technical SEO, along with cleaning up URLs and a sound internal linking structure.
If you'd like someone to run these checks on your site and sort out redirects, canonicals and sitemaps in one piece of work, it's one of the things our SEO service covers.
Frequently asked questions
An absolute URL contains the full address: protocol, host and path, for example https://www.example.co.uk/blog/article/. A relative URL contains only part of it, for example /blog/article/, and the browser completes it starting from the address of the page the link is on.
For internal links in the body of a page Google treats both forms the same way, as long as the site answers on a single version. If several host or protocol variants return a 200, absolute URLs reduce the risk of duplicates. Canonicals, XML sitemaps, hreflang and the Sitemap line in robots.txt should always use the absolute form.
Technically the browser resolves it, but Google's documentation explicitly asks you to use absolute paths both in the link rel=canonical tag and in the HTTP header. A relative canonical leaves the crawler to rebuild host and protocol, which is exactly what the canonical is meant to pin down.
No. Google asks for fully qualified, absolute URLs and says it crawls them exactly as written. The sitemaps.org protocol also states that every URL in the loc field must begin with the protocol, for example https.
It's an address that starts with two slashes, for example //www.example.co.uk/page/, and inherits http or https from the page it's on. On a site served only over https it brings no benefit: write https:// directly.
When you pick an internal page from the link search in the block editor, WordPress inserts the full permalink. Of the 3,729 internal links in the 263 Italian articles on the Visilay blog, 100% were absolute. Relative links can still appear in the final HTML if a plugin, the theme or a service such as Cloudflare adds them.
One thing the industry rarely says: the absolute-versus-relative debate is almost always a symptom. Whoever raises it usually has a site that answers on several addresses, and is trying to fix in the links a problem that lives in the server configuration. Once the redirects are sorted, the question stops mattering for links in the body of the page and only applies to the five fields in the table, where the answer is already written down.
