နည်းပညာ SEO
HTTP Link Header SEO စစ်ဆေးကိရိယာ
URL တစ်ခု ရိုက်ထည့်ပါ။ ကျွန်ုပ်တို့သည် server ဘက်မှ ရယူပြီး RFC 8288 အတိုင်း HTTP Link response header ထဲမှ rel="canonical"၊ rel="alternate" hreflang နှင့် rel="next"/"prev" entry များကို parse လုပ်ပါမည်— ထို့နောက် တူညီသောစာမျက်နှာရှိ HTML <link> tag များနှင့် ချိန်ညှိစစ်ဆေးပြီး ပဋိပက္ခရှိလျှင် ဖော်ပြပါမည်။
reCAPTCHA ဖြင့် ကာကွယ်ထားသည်။ ကျွန်ုပ်တို့သည် URL ကို server ဘက်မှ ရယူပြီး (SSRF ကာကွယ်ထားသည်) ၎င်း၏ response header များကို ဖတ်ပါသည်— မည်သည့်အရာမျှ သိမ်းဆည်းခြင်း မရှိပါ။
Link header အဘယ်ကြောင့် အရေးကြီးသနည်း
canonical နှင့် hreflang စစ်ဆေးကိရိယာအားလုံးနီးပါးသည် စာမျက်နှာ၏ <head> ထဲရှိ HTML <link> tag များကိုသာ ကြည့်ကြသည်။ RFC 8288 သည် တူညီသော signal များကို ကြေညာနိုင်သော၊ တန်ဖိုးတူညီသည့် ဒုတိယနေရာတစ်ခုကို သတ်မှတ်ထားသည်— HTTP Link: response header ပင်ဖြစ်သည်။ Google သည် ၎င်းကို ရှင်းလင်းစွာ မှတ်တမ်းတင်ပြီး လေးစားသည်၊ WordPress နှင့် CDN များစွာသည် ၎င်းကို အလိုအလျောက် ပို့ဆောင်ကြသည်၊ ၎င်းသည် HTML မဟုတ်သော resource — PDF၊ ပုံ၊ JSON API တုံ့ပြန်ချက် — တစ်ခုတွင် canonical သို့မဟုတ် hreflang သတ်မှတ်ရန် တစ်ခုတည်းသော နည်းလမ်းဖြစ်သည်၊ အကြောင်းမှာ ထိုအရာများတွင် <link> tag ထည့်ရန် <head> ကိုယ်တိုင် မရှိသောကြောင့်ဖြစ်သည်။ မည်သည့်နေရာမျှ မပြသောကြောင့်၊ CDN edge rule တစ်ခုက HTML tag နှင့် တိတ်တဆိတ် ကွဲလွဲနေသော header သတ်မှတ်ထားခြင်း သို့မဟုတ် ဤနည်းဖြင့် canonical သတ်မှတ်ရန် မည်သူမျှ မတွေးမိသော PDF တစ်ခုသည် browser တွင်လည်းကောင်း HTML ကိုသာဖတ်သည့် ကိရိယာအားလုံးတွင်လည်းကောင်း လုံးဝမမြင်ရပါ။
ဤကိရိယာ၏ စစ်ဆေးမှုများ
regex ခန့်မှန်းချက်မဟုတ်ဘဲ သင့် server ပို့ဆောင်ခဲ့သော response header အစစ်ကို ဖတ်သည့် တကယ့် RFC 8288 parser တစ်ခုဖြစ်သည်။
RFC 8288 Link header parsing
ကော်မာဖြင့်ခွဲထားသော entry များစွာ၊ ကိုးကားစာလုံးပါ parameter များနှင့် တန်ဖိုးများစွာပါသော rel list များအပါအဝင် Link: header value ကို structure ရှိသော rel=canonical၊ rel=alternate နှင့် rel=next/prev entry များအဖြစ် parse လုပ်ပြီး မှန်ကန်သော link-value အဖြစ် parse မလုပ်နိုင်သော segment ကို ဖော်ပြသည်။
Header vs HTML canonical ပဋိပက္ခ
header ၏ rel="canonical" ပစ်မှတ်ကို စာမျက်နှာ၏ HTML <link rel="canonical"> tag နှင့် နှိုင်းယှဉ်သည်။ မကိုက်ညီမှုသည် တကယ်ရှိသည့်၊ တိတ်တဆိတ်ဖြစ်တတ်သော ပြဿနာဖြစ်သည်— search engine များသည် signal နှစ်ခုစလုံးအနက် တစ်ခုခုကို လက်ခံနိုင်သဖြင့် canonicalization သည် မဆုံးဖြတ်နိုင်သည့်အခြေအနေ ဖြစ်သွားနိုင်သည်။ header canonical တစ်ခုထက်ပိုမိုခြင်း၊ ဒိုမိန်းကျော်ပစ်မှတ်နှင့် ရယူထားသော URL ကို ကိုယ်တိုင်ရည်ညွှန်းခြင်းရှိမရှိကိုလည်း ဖော်ပြသည်။
Header မှတဆင့် hreflang
rel="alternate"; hreflang="..." header entry တိုင်း၏ ဘာသာစကားကုဒ်ကို စိစစ်ပြီး entry ၂ခု (သို့) ထို့ထက်ပိုပါက x-default မရှိခြင်း၊ ကိုယ်တိုင်ရည်ညွှန်း entry မရှိခြင်းနှင့် ကွဲပြားသော URL များကို ညွှန်းသော ထပ်နေသည့်ကုဒ်များကို စစ်ဆေးသည်— ထို့နောက် ပဋိပက္ခရှာရန် စုစုပေါင်းကို စာမျက်နှာ၏ HTML hreflang tag များနှင့် ချိန်ညှိသည်။
HTML မဟုတ်သော resource ဖုံးလွှမ်းမှု
PDF၊ ပုံ (သို့) API တုံ့ပြန်ချက် (HTML မရှိသဖြင့် <link> tag ရှိနိုင်ခြေမရှိပါ) အတွက်၊ header canonical လုံးဝ မပို့ခဲ့သည့် အခြေအနေကို ဖော်ပြသည်— ဆိုလိုသည်မှာ ထို resource တွင် search engine များအတွက် canonicalization signal လုံးဝမရှိခြင်းဖြစ်ပြီး ဤအချက်ကို လွတ်သွားရန် အလွန်လွယ်ကူသည်။
မကြာခဏမေးလေ့ရှိသောမေးခွန်းများ
HTTP Link header ဆိုတာဘာလဲ၊ ကျွန်ုပ်၏ site က ဘာကြောင့် ၎င်းကို ပို့ဆောင်သနည်း။
၎င်းသည် RFC 8288 ဖြင့် သတ်မှတ်ထားသော response header တစ်ခုဖြစ်ပြီး ပုံမှန်အားဖြင့် HTML <link> tag အဖြစ် ရေးသားလေ့ရှိသော rel-based ဆက်နွှယ်မှုများ (canonical၊ alternate၊ next၊ prev စသည်) ကို သယ်ဆောင်သည်— ကွာခြားချက်မှာ ၎င်းသည် HTML ဖြစ်စေ မဖြစ်စေ response မည်သည့်အမျိုးအစားအတွက်မဆို အလုပ်လုပ်ခြင်းဖြစ်သည်။ WordPress core သည် Link header အချို့ကို အလိုအလျောက် ပို့ဆောင်သည်၊ CDN နှင့် reverse proxy အများအပြားသည် edge တွင် ၎င်းတို့ကို ထည့်သွင်း (သို့) ပြန်ရေးနိုင်ပြီး တစ်ခါတစ်ရံ origin site က မသိဘဲ ဖြစ်တတ်သည်။
header canonical သည် ကျွန်ုပ်၏ HTML canonical tag နှင့် ကွာခြားနေသည်— ဒါ bug လား။
အများစုမှာ ဟုတ်ပါသည်။ Google ၏ ကိုယ်ပိုင် documentation က နှစ်ခုစလုံးသည် valid signal ဖြစ်သည်ဟု ဆိုသော်လည်း ကွဲလွဲသောအခါ မည်သည့်တစ်ခုက အနိုင်ရမည်ကို အာမခံချက် မပေးပါ— လက်တွေ့တွင် ၎င်းသည် ထို URL ၏ canonicalization ကို မှန်းဆမရနိုင်စေရုံသာဖြစ်သည်။ CDN၊ cache layer (သို့) plugin တစ်ခုခုက သင့် HTML template နှင့် သီးခြားစီ header ကို ထည့်သွင်းနေခြင်းရှိမရှိ စစ်ဆေးပြီး နှစ်ခုကို ကိုက်ညီအောင် ပြင်ဆင်ပါ။
HTML <link> tag လုံးဝမပါဘဲ hreflang ကို အသုံးပြုနိုင်ပါသလား။
ရပါသည်— header ပုံစံသည် tag ပုံစံနှင့် အပြည့်အဝ ညီမျှပြီး HTML မဟုတ်သော resource (ဥပမာ PDF) များကို hreflang tag တပ်ရန် (သို့) HTML template ကို မထိမခိုက်ဘဲ response တစ်ခုတွင် hreflang ထည့်ရန် စံနှုန်းနည်းလမ်းဖြစ်သည်။ စည်းမျဉ်းတူညီပါသည်— ဘာသာစကားမူကွဲတိုင်းသည် ၎င်းကိုယ်တိုင် (self-reference) ကို list ထဲတွင် ပါဝင်သင့်ပြီး၊ မူကွဲနှစ်ခု (သို့) ထို့ထက်ပိုပါက x-default ကို အကြံပြုပါသည်။
Google သည် Link response header ကို တကယ် အသုံးပြုပါသလား။
ဟုတ်ကဲ့ဖြစ်သည်။ Google Search Central documentation သည် rel="canonical" နှင့် rel="alternate" hreflang နှစ်ခုစလုံးကို သတ်မှတ်ရန် ထောက်ခံထားသော နည်းလမ်းအဖြစ် HTTP header ကို ရှင်းလင်းစွာ ဖော်ပြထားပြီး ဤ mechanism ရှိနေရသည့် အကြောင်းရင်းအဖြစ် HTML မဟုတ်သော file များကို အထူးဖော်ပြထားသည်။
ကျွန်ုပ်၏ URL (သို့) ၎င်း၏ content ကို တစ်နေရာရာတွင် သိမ်းဆည်းထားပါသလား။
မသိမ်းဆည်းပါ။ ရယူခြင်းသည် ဤစစ်ဆေးမှုတစ်ခုတည်းအတွက်သာ server ဘက်တွင် ဖြစ်ပေါ်ပြီး ရလဒ်ကို သင့် browser သို့ တိုက်ရိုက် ပြန်ပို့ပါသည်— rate-limit counter တစ်ခုမှလွဲ၍ database (သို့) log တွင် မည်သည့်အရာမျှ ရေးမထားပါ။