SEO បច្ចេកទេស

ឧបករណ៍ពិនិត្យ HTTP Link Header SEO

បញ្ចូល URL មួយ។ យើងទាញយកនៅផ្នែក server ហើយញែក HTTP Link response header សម្រាប់ធាតុ rel="canonical", rel="alternate" hreflang និង rel="next"/"prev" ស្របតាម RFC 8288 — បន្ទាប់មកប្រៀបធៀបជាមួយស្លាក HTML <link> នៅលើទំព័រដដែល ហើយសម្គាល់ទំនាស់ណាមួយ។

ការពារដោយ reCAPTCHA។ យើងទាញយក URL នៅផ្នែក server (ការពារ SSRF) ហើយអានតែ response header របស់វា — គ្មានអ្វីត្រូវបានរក្សាទុកឡើយ។

ហេតុអ្វី Link header មានសារៈសំខាន់

ឧបករណ៍ពិនិត្យ canonical និង hreflang ស្ទើរតែទាំងអស់ សម្លឹងតែស្លាក HTML <link> នៅក្នុង <head> របស់ទំព័រប៉ុណ្ណោះ។ RFC 8288 កំណត់ទីតាំងទីពីរ ដែលមានសុពលភាពស្មើគ្នា សម្រាប់ប្រកាសសញ្ញាដូចគ្នា — នោះគឺ HTTP Link: response header។ Google កត់ត្រា និងគោរពវាយ៉ាងច្បាស់លាស់ WordPress និង CDN ជាច្រើនផ្ញើវាដោយស្វ័យប្រវត្តិ ហើយវាគឺជាមធ្យោបាយតែមួយគត់ដើម្បីកំណត់ canonical ឬ hreflang សម្រាប់ធនធានមិនមែន HTML — ឯកសារ PDF រូបភាព ចម្លើយ JSON API — ព្រោះធនធានទាំងនោះគ្មាន <head> ដើម្បីដាក់ស្លាក <link> បានឡើយ។ ដោយសារគ្មានកន្លែងណាបង្ហាញវា header ដែលកំណត់ដោយច្បាប់ CDN edge ដោយស្ងាត់ស្ងៀមខុសពីស្លាក HTML ឬឯកសារ PDF ដែលគ្មាននរណាបានគិតកំណត់ canonical តាមរបៀបនេះ ក៏មិនអាចមើលឃើញទាំងនៅក្នុងកម្មវិធីរុករក ហើយក៏មិនអាចមើលឃើញនៅក្នុងឧបករណ៍ណាមួយដែលអានតែ HTML ដែរ។

អ្វីដែលឧបករណ៍នេះពិនិត្យ

កម្មវិធីញែក RFC 8288 ពិតប្រាកដ — មិនមែនការទាយ regex ទេ — ដែលអានលើ response header ពិតដែលម៉ាស៊ីនមេរបស់អ្នកបានផ្ញើ។

ការញែក Link header តាម RFC 8288

ញែកតម្លៃ header Link: ដើម — រួមទាំងធាតុច្រើនបំបែកដោយសញ្ញាក្បៀស ប៉ារ៉ាម៉ែត្រក្នុងសញ្ញាសម្រង់ និងបញ្ជី rel ច្រើនតម្លៃ — ទៅជាធាតុ rel=canonical, rel=alternate និង rel=next/prev ដែលមានរចនាសម្ព័ន្ធ ព្រមទាំងសម្គាល់ផ្នែកណាដែលមិនអាចញែកជា link-value ត្រឹមត្រូវបាន។

ទំនាស់ canonical រវាង header និង HTML

ប្រៀបធៀបគោលដៅ rel="canonical" នៅក្នុង header ជាមួយស្លាក HTML <link rel="canonical"> របស់ទំព័រ។ ភាពមិនត្រូវគ្នាគឺជាបញ្ហាពិត ដែលកើតឡើងដោយស្ងាត់ស្ងៀម៖ ម៉ាស៊ីនស្វែងរកអាចគោរពសញ្ញាណាមួយក៏បាន ដែលធ្វើឱ្យ canonicalization ក្លាយជាមិនប្រាកដប្រជា។ ក៏សម្គាល់ផងដែរ ប្រសិនបើមាន canonical header ច្រើនជាងមួយ គោលដៅឆ្លងដែន និងថាតើវាយោងខ្លួនឯង (self-reference) ទៅ URL ដែលបានទាញយកឬអត់។

Hreflang តាមរយៈ header

ផ្ទៀងផ្ទាត់លេខកូដភាសានៃធាតុ header rel="alternate"; hreflang="..." នីមួយៗ ពិនិត្យរកករណីខ្វះ x-default នៅពេលមានធាតុ ២ ឬច្រើនជាងនេះ ខ្វះធាតុយោងខ្លួនឯង និងលេខកូដស្ទួនដែលចង្អុលទៅ URL ខុសគ្នា — បន្ទាប់មកប្រៀបធៀបសំណុំទាំងមូលជាមួយស្លាក hreflang HTML របស់ទំព័រ ដើម្បីរកទំនាស់។

ការគ្របដណ្ដប់ធនធានមិនមែន HTML

សម្រាប់ឯកសារ PDF រូបភាព ឬចម្លើយ API (គ្មាន HTML ដូច្នេះស្លាក <link> មិនអាចមានឡើយ) សម្គាល់ករណីដែលគ្មាន canonical header ត្រូវបានផ្ញើ — មានន័យថាធនធាននោះគ្មានសញ្ញា canonicalization ទាល់តែសោះសម្រាប់ម៉ាស៊ីនស្វែងរក ដែលងាយនឹងមើលរំលង។

សំណួរដែលសួរញឹកញាប់

តើ HTTP Link header គឺជាអ្វី ហើយហេតុអ្វីបានជាគេហទំព័ររបស់ខ្ញុំផ្ញើវា?

វាគឺជា response header កំណត់ដោយ RFC 8288 ដែលផ្ទុកទំនាក់ទំនងផ្អែកលើ rel ដូចគ្នា (canonical, alternate, next, prev និងច្រើនទៀត) ដែលធម្មតាសរសេរជាស្លាក HTML <link> — ខុសគ្នាត្រង់ថាវាដំណើរការសម្រាប់ចម្លើយណាមួយ HTML ឬអត់ក៏បាន។ WordPress core ផ្ញើ Link header មួយចំនួនដោយស្វ័យប្រវត្តិ CDN និង reverse proxy ជាច្រើនអាចបញ្ចូល ឬសរសេរជាថ្មីនៅ edge ជួនកាលដោយគេហទំព័រដើមមិនដឹង។

canonical ក្នុង header ខុសពីស្លាក canonical HTML របស់ខ្ញុំ — តើនេះជា bug ទេ?

ស្ទើរតែជានិច្ចហើយ។ ឯកសារផ្លូវការរបស់ Google ខ្លួនឯងបញ្ជាក់ថាទាំងពីរជាសញ្ញាត្រឹមត្រូវ ប៉ុន្តែមិនធានាថាមួយណានឹងឈ្នះនៅពេលពួកវាមិនស្របគ្នាទេ — ជាក់ស្តែងវាធ្វើឱ្យ canonicalization របស់ URL នោះមិនអាចទាយទុកជាមុនបាន។ ពិនិត្យមើលថាតើ CDN ស្រទាប់ cache ឬកម្មវិធីជំនួយកំពុងបញ្ចូល header ដោយឯករាជ្យពី template HTML របស់អ្នកឬអត់ ហើយធ្វើឱ្យទាំងពីរស្របគ្នា។

តើខ្ញុំអាចប្រើ hreflang ដោយគ្មានស្លាក HTML &lt;link&gt; ទាល់តែសោះបានទេ?

បាន — ទម្រង់ header មានតម្លៃស្មើគ្នាទាំងស្រុងជាមួយស្លាក ហើយជាវិធីស្តង់ដារសម្រាប់ដាក់ស្លាក hreflang លើធនធានមិនមែន HTML (ឧទាហរណ៍ PDF) ឬបន្ថែម hreflang ទៅចម្លើយដោយមិនប៉ះពាល់ template HTML។ ច្បាប់ដូចគ្នាអនុវត្ត៖ ភាសាកម្មងនីមួយៗគួរតែរាយខ្លួនឯង (self-reference) ហើយ x-default ត្រូវបានណែនាំនៅពេលអ្នកមានកម្មង ២ ឬច្រើនជាងនេះ។

តើ Google ពិតជាប្រើ Link response header ដែរឬទេ?

បាទ/ចាស៎។ ឯកសារ Google Search Central រាយបញ្ជី HTTP header យ៉ាងច្បាស់ថាជាមធ្យោបាយដែលគាំទ្រសម្រាប់កំណត់ទាំង rel="canonical" និង rel="alternate" hreflang ដោយបញ្ជាក់ជាពិសេសថាឯកសារមិនមែន HTML គឺជាមូលហេតុដែលយន្តការនេះមាន។

តើ URL របស់ខ្ញុំ ឬមាតិការបស់វា ត្រូវបានរក្សាទុកនៅកន្លែងណាមួយឬទេ?

អត់ទេ។ ការទាញយកកើតឡើងនៅផ្នែក server សម្រាប់តែការពិនិត្យលើកនេះមួយប៉ុណ្ណោះ ហើយលទ្ធផលត្រូវបានបញ្ជូនត្រឡប់ទៅកម្មវិធីរុករករបស់អ្នកដោយផ្ទាល់; គ្មានអ្វីត្រូវបានសរសេរទៅមូលដ្ឋានទិន្នន័យ ឬកំណត់ហេតុ ក្រៅពីរាប់ចំនួន rate-limit ឡើយ។