Technical SEO
HTTP Link Header SEO Checker
Enter a URL. We fetch it server-side and parse the HTTP Link response header for rel="canonical", rel="alternate" hreflang, and rel="next"/"prev" entries per RFC 8288 — then cross-check them against the HTML <link> tags on the same page and flag any conflict, lah.
Protected by reCAPTCHA. We fetch the URL server-side (SSRF-guarded) and read its response headers — nothing is stored, confirm.
Why the Link header matters
Every canonical and hreflang checker looks at the HTML <link> tags in a page's <head>. RFC 8288 defines a second, equally valid place to declare the same signals: the HTTP Link: response header. Google explicitly documents and honors it, WordPress and several CDNs emit it automatically, and it is the only way to canonicalize or hreflang-tag a non-HTML resource — a PDF, an image, a JSON API response — because those have no <head> to put a <link> tag in. Because nothing renders it, a header set by a CDN edge rule that silently disagrees with the HTML tag, or a PDF nobody thought to canonicalize this way, is invisible in a browser and in every tool that only reads HTML.
What this checks
A real RFC 8288 parser — not a regex guess — reading the actual response header your server sent.
RFC 8288 Link header parsing
Parses the raw Link: header value — including multiple comma-separated entries, quoted parameters and multi-value rel lists — into structured rel=canonical, rel=alternate and rel=next/prev entries, and flags any segment that does not parse as a valid link-value.
Header vs. HTML canonical conflict
Compares the header's rel="canonical" target against the page's HTML <link rel="canonical"> tag. A mismatch is a real, silent problem: search engines may honor either signal, effectively making canonicalization non-deterministic. Also flags more than one header canonical, a cross-domain target, and whether it self-references the fetched URL.
Hreflang via the header
Validates every rel="alternate"; hreflang="..." header entry's language code, checks for a missing x-default among 2+ entries, a missing self-referencing entry, and duplicate codes pointing at different URLs — then cross-checks the whole set against the page's HTML hreflang tags for a conflict.
Non-HTML resource coverage
For a PDF, image or API response (no HTML, so no <link> tags are even possible), flags the case where no header canonical was sent — meaning the resource has zero canonicalization signal for search engines, which is easy to overlook entirely, sian.
Frequently asked questions
What is the HTTP Link header and why would my site send it?
It is a response header, defined by RFC 8288, that carries the same rel-based relationships (canonical, alternate, next, prev, and more) normally written as HTML <link> tags — except it works for any response, HTML or not. WordPress core emits some Link headers automatically; many CDNs and reverse proxies can inject or rewrite them at the edge, sometimes without the origin site's knowledge.
The header canonical differs from my HTML canonical tag — is that a bug?
Almost always, yes lor. Google's own documentation says both are valid signals, but does not guarantee which one wins when they disagree — in practice this just makes canonicalization unpredictable for that URL. Check whether a CDN, caching layer or plugin is injecting the header independently of your HTML template, and make the two match.
Can I use hreflang without any HTML <link> tags?
Yes — the header form is fully equivalent and is the standard way to hreflang-tag non-HTML resources (PDFs, for example) or to add hreflang to a response without touching the HTML template. The same rules apply: every language variant should list itself (self-reference), and an x-default is recommended once you have two or more variants.
Does Google actually use the Link response header?
Yes. Google's Search Central documentation explicitly lists the HTTP header as a supported way to specify both rel="canonical" and rel="alternate" hreflang, specifically calling out non-HTML files as the reason it exists.
Is my URL or its content stored anywhere?
No lah. The fetch happens server-side for this one check and the result is returned directly to your browser; nothing is written to a database or log beyond a rate-limit counter.