Technical SEO
HTTP Link Header SEO Checker
Maglagay ng URL. Kukunin namin ito sa server-side at susuriin ang HTTP Link response header para sa mga entry na rel="canonical", rel="alternate" hreflang, at rel="next"/"prev" ayon sa RFC 8288 — pagkatapos ay itutugma ito sa mga HTML <link> tag sa parehong page at ibabandera ang anumang salungatan.
Protektado ng reCAPTCHA. Kinukuha namin ang URL sa server-side (may proteksyon sa SSRF) at binabasa ang response header nito — walang naiimbak.
Bakit mahalaga ang Link header
Halos lahat ng checker ng canonical at hreflang ay tumitingin lang sa mga HTML <link> tag sa <head> ng isang page. Tinutukoy ng RFC 8288 ang pangalawang lugar, na kasinghalaga rin, para ideklara ang parehong mga signal na ito: ang HTTP Link: response header. Malinaw itong dokumentado at iginagalang ng Google, awtomatikong ipinapadala ito ng WordPress at ilang CDN, at ito ang tanging paraan para mag-canonicalize o maglagay ng hreflang sa isang resource na hindi HTML — isang PDF, larawan, o JSON API response — dahil ang mga ito ay walang <head> na mapaglalagyan ng <link> tag. Dahil walang naglalarawan nito, ang isang header na itinakda ng CDN edge rule na tahimik na sumasalungat sa HTML tag, o isang PDF na hindi kailanman naisip na dapat mag-canonicalize sa ganitong paraan, ay hindi nakikita kahit sa browser o sa anumang tool na HTML lang ang binabasa.
Ano ang sinusuri ng tool na ito
Isang tunay na RFC 8288 parser — hindi hula-hula na regex — na binabasa ang aktwal na response header na ipinadala ng iyong server.
Pag-parse ng Link header ayon sa RFC 8288
Sinusuri ang raw na halaga ng Link: header — kasama ang maramihang entry na pinaghihiwalay ng kuwit, mga parameter na may quote, at mga listahan ng rel na may maraming halaga — at ginagawang structured na mga entry na rel=canonical, rel=alternate, at rel=next/prev, at ibinabandera ang anumang segment na hindi valid na link-value.
Salungatan ng canonical: header laban sa HTML
Inihahambing ang target ng rel="canonical" sa header laban sa HTML <link rel="canonical"> tag ng page. Ang hindi pagtutugma ay isang totoo at tahimik na problema: maaaring sundin ng mga search engine ang alinman sa dalawang signal, kaya ang canonicalization ay nagiging hindi tiyak. Ibinabandera rin kung mahigit isa ang canonical sa header, isang target na cross-domain, at kung self-referencing ba ito sa URL na kinuha.
Hreflang sa pamamagitan ng header
Sinusuri ang language code ng bawat entry na rel="alternate"; hreflang="..." sa header, sinusuri kung nawawala ang x-default kapag may 2 o higit pang entry, nawawalang self-referencing entry, at mga duplicate code na tumuturo sa iba't ibang URL — pagkatapos ay itinutugma ang buong set laban sa mga HTML hreflang tag ng page para sa salungatan.
Saklaw para sa resource na hindi HTML
Para sa PDF, larawan, o API response (walang HTML kaya imposibleng magkaroon ng <link> tag), ibinabandera ang kaso kung saan walang ipinadalang canonical sa header — ibig sabihin, walang anumang canonicalization signal ang resource para sa mga search engine, na madaling hindi mapansin nang lubusan.
Mga madalas itanong
Ano ang HTTP Link header at bakit ito ipapadala ng aking site?
Ito ay isang response header, na tinutukoy ng RFC 8288, na nagdadala ng parehong mga relasyong nakabatay sa rel (canonical, alternate, next, prev, at higit pa) na karaniwang isinusulat bilang HTML <link> tag — maliban sa gumagana ito para sa anumang response, HTML man o hindi. Awtomatikong nagpapadala ng ilang Link header ang WordPress core; maraming CDN at reverse proxy ang maaaring mag-inject o mag-rewrite ng mga ito sa edge, minsan nang hindi alam ng orihinal na site.
Iba ang canonical sa header kaysa sa aking HTML canonical tag — bug ba ito?
Halos palagi, oo. Sinasabi mismo ng dokumentasyon ng Google na parehong valid ang dalawang signal, pero hindi ginagarantiya kung alin ang mananalo kapag magkasalungat sila — sa praktikal, nagiging hindi matatakdaan ang canonicalization ng URL na iyon. Suriin kung may CDN, caching layer, o plugin na nag-i-inject ng header nang hiwalay sa iyong HTML template, at pagtugmain ang dalawa.
Puwede ba akong gumamit ng hreflang nang walang anumang HTML <link> tag?
Oo — ganap na katumbas ang anyong header ng tag, at ito ang karaniwang paraan para maglagay ng hreflang tag sa resource na hindi HTML (halimbawa, PDF) o magdagdag ng hreflang sa isang response nang hindi ginagalaw ang HTML template. Pareho pa rin ang mga tuntunin: dapat ilista ng bawat variant ng wika ang sarili nito (self-reference), at inirerekomenda ang x-default kapag mayroon ka nang dalawa o higit pang variant.
Talaga bang ginagamit ng Google ang Link response header?
Oo. Malinaw na itinatala ng dokumentasyon ng Google Search Central ang HTTP header bilang suportadong paraan para tukuyin ang parehong rel="canonical" at rel="alternate" hreflang, at partikular nitong binanggit ang mga file na hindi HTML bilang dahilan kung bakit umiiral ang mekanismong ito.
Naiimbak ba kahit saan ang aking URL o ang nilalaman nito?
Hindi. Nangyayari ang pagkuha sa server-side para lamang sa isang beses na pagsusuring ito at direktang ibinabalik ang resulta sa iyong browser; walang isinusulat sa database o log maliban sa isang rate-limit counter.