12 خطای رایج hreflang و روش تشخیص آنها
بیشتر خطاهای hreflang به یک صفحه برنمیگردد، به سیستم برمیگردد. دوازده خطای رایج و یک روش اعتبارسنجی سهلایه برای یافتن آنها در production.
نوشته Roozbeh Nazari · CEO
hreflang یکی از پرخطاترین بخشهای سئوی فنی است. دلیلش پیچیدگی آن نیست، بلکه این است که در سکوت شکست میخورد. یک پیکربندی اشتباه هیچ پیام خطایی تولید نمیکند، صفحه عادی به نظر میرسد و کسی متوجه نمیشود. مشکل تازه ماهها بعد خودش را نشان میدهد، وقتی صفحهای به زبان اشتباه در کشور اشتباه رتبه میگیرد.
پیشتر در پلیبوک معماری سئوی چندزبانه توضیح داده بودیم که این معماری در حوزه کلینیکها چگونه ساخته میشود. این نوشته مکمل آن است: دوازده خطای مشخص که پس از برپایی معماری، بیشترین تکرار را در محیط production دارند و روشی برای گرفتن آنها.
خطاهای دوسویگی و ساختار گروه
چهار خطای اول به منطق پایه hreflang برمیگردد: hreflang یک تگ صفحه نیست، اعلان یک گروه است.
1. اعلان یکطرفه. صفحه ترکی به صفحه انگلیسی اشاره میکند اما صفحه انگلیسی به ترکی برنمیگردد. مستندات Google دوسویه بودن اعلانها را شرط میداند و اعلانهای یکطرفه ممکن است نادیده گرفته شوند. این رایجترین خطای فهرست است.
2. نبودن ارجاع به خود. هر صفحه باید در کنار بقیه صفحههای گروه، خودش را هم فهرست کند. صفحهای که ارجاع به خود ندارد، بهجای عضو گروه، مثل ناظری از بیرون رفتار میکند.
3. عضو جاافتاده. گروه چهار زبان دارد اما بعضی صفحهها فقط سه زبان را فهرست میکنند. این معمولاً از تفاوت قالبها میآید: قالب بلاگ چهار زبان را چاپ میکند در حالی که قالب خدمات روی سه زبان مانده است.
4. ناسازگاری عضویت گروه از صفحهای به صفحه دیگر. صفحه الف به ب و ج اشاره میکند و صفحه ب به الف و د. مجموعهای منسجم شکل نمیگیرد و کل گروه بیاعتبار میشود.
سرچشمه مشترک این چهار خطا تقریباً همیشه یکی است: hreflang بهجای اینکه از یک منبع حقیقت واحد بیاید، قالببهقالب تولید میشود.
خطاهای کد و URL
چهار خطای بعدی مکانیکیتر است، اما دستکمی از قبلیها ندارد.
5. کد زبان نامعتبر. رایجترین موارد، کدهای منطقهای ساختگی و درهمآمیختن زبان با کشور است. برای عربی، «ar» یک کد زبان است و «ar-AE» ترکیب زبان و منطقه. «uk» یعنی اوکراینی، نه بریتانیا.
6. استفاده از کد منطقه بهتنهایی. مقدار hreflang نمیتواند بدون کد زبان فقط کد کشور داشته باشد. این تعریفی است که بیصدا نادیده گرفته میشود.
7. استفاده از URL نسبی. مقادیر hreflang باید URL مطلق باشد، همراه با پروتکل. پیکربندیهایی که مسیر نسبی مینویسند، اغلب همان حالت را از staging به production آوردهاند.
8. اشاره به URLهای ریدایرکتشده یا غیرقابلدسترس. نشانیای که hreflang به آن اشاره میکند باید نشانی نهایی باشد. اعلانی که به یک ریدایرکت، به 404 یا به صفحهای مسدودشده با robots.txt اشاره کند، گروه را میشکند.
سیگنالهای متناقض
چهار خطای آخر سختترین خطاها برای دیدهشدن است، چون خود کد hreflang درست به نظر میرسد. مشکل این است که صفحه از جای دیگری حرف دیگری میزند.
9. تناقض با canonical. صفحه با hreflang میگوید «من نسخه عربی هستم» اما canonical آن به نسخه انگلیسی اشاره میکند. در این حالت نسخه عربی دیگر صفحهای مستقل به شمار نمیآید. هر locale باید canonical خودش باشد.
10. ریدایرکت خودکار. حتی اگر hreflang درست پیکربندی شده باشد، ریدایرکت اجباری بر پایه IP یا زبان مرورگر، خزنده را روی یک نسخه قفل میکند. سازوکار آن و یک روال آزمون پانزدهدقیقهای را در نوشتهمان درباره ریدایرکت خودکار زبان شرح دادهایم.
11. ناهمخوانی زبان صفحه با اعلان. hreflang میگوید «fa» اما متن صفحه تا حد زیادی انگلیسی مانده است؛ معمولاً نتیجه ترجمه نیمهکاره. وقتی اعلان و محتوا با هم در تناقض باشند، محتوا برنده میشود نه اعلان.
12. کاربرد نادرست x-default. مقدار x-default صفحه پیشفرض را برای کاربرانی نشان میدهد که زبانشان تطبیق داده نشده است؛ معنای «مهمترین زبان» نمیدهد. دادن x-default به بیش از یک صفحه، یا اصلاً ندادن آن، دو وضعیت متفاوتاند اما هر دو باید اصلاح شوند.
چرا Search Console بهتنهایی کافی نیست
نخستین واکنش تیمها این است که وضعیت hreflang را از Search Console دنبال کنند. این کار منطقی است، اما دو محدودیت ساختاری دارد.
اول پوشش: گزارشها بر صفحههایی استوارند که Google آنها را خزیده و پردازش کرده است. یک خطای سیستماتیک در نسخه زبانی تازهای که هنوز خزیده نشده، ممکن است هفتهها در گزارش دیده نشود. منتظر ماندن برای اعتبارسنجی locale تازهمنتشرشده یعنی از دست دادن همان دورهای که خطا پرهزینهترین گسترش را دارد.
دوم دقت: گزارشها به شما میگویند مشکلی هست، اما نمیگویند کدام قالب آن را تولید کرده است. بیشتر این دوازده خطا، خطای قالب است نه خطای تکتک صفحهها. وقتی قالب را نمیبینید، شروع میکنید به اصلاح صفحهبهصفحه و همان خطا با انتشار بعدی برمیگردد.
به همین دلیل درستتر است Search Console را نه ابزار اعتبارسنجی، بلکه ابزار پایش پس از اعتبارسنجی بدانیم. خزش خودتان خطا را پیدا میکند و Search Console در طول زمان نشان میدهد که آیا اصلاح در سمت Google بازتاب یافته است یا نه. این دو جای یکدیگر را نمیگیرند.
یک بحث sitemap هم هست: ارائه اعلانهای hreflang از راه sitemap با قالب XML بهجای تگهای صفحه، بهویژه در سایتهای پرصفحه، پراکندگی قالبها را کم میکند. تغییر روش، خطاها را خودبهخود حل نمیکند اما ساختن یک منبع حقیقت واحد را آسانتر میکند — و ریشه خطاهای این فهرست در بیشتر موارد دقیقاً نبودِ همین منبع است.
تشخیص در production: اعتبارسنجی سهلایه
هیچیک از این خطاها را نمیتوان با باز کردن چشمی صفحهها بهشکل قابلاتکا پیدا کرد. اعتبارسنجی تکرارپذیر به سه لایه نیاز دارد.
لایه اول: خزش روی HTML رندرشده. کل سایت را بخزید و اعلانهای hreflang هر URL را استخراج کنید. نکته حیاتی این است که HTML رندرشده را بگیرید نه HTML منبع، چون تگهای hreflang که سمت کلاینت افزوده میشوند در HTML منبع دیده نمیشوند. خروجی باید فهرست localeهای اعلامشده برای هر URL باشد.
لایه دوم: اعتبارسنجی گراف. خروجی خزش را یک گراف جهتدار در نظر بگیرید و این موارد را برنامهنویسیشده بررسی کنید: آیا هر یال متناظر خود را دارد، آیا هر گره خودش را در بر میگیرد، آیا اندازه هر مؤلفه برابر با تعداد زبانهای مورد انتظار است، آیا کدهای زبان در فهرست معتبر هستند، آیا URLهای مقصد کد 200 برمیگردانند. این پنج بررسی، بیشتر آن دوازده خطا را بهصورت خودکار میگیرد.
لایه سوم: بررسی تناقض. برای هر URL، اعلان hreflang را با canonical، با ویژگی lang صفحه و با مدخل موجود در sitemap مقایسه کنید. هر ناهمخوانی میان این سه منبع یک یافته است.
خروجی این سه لایه باید یک رویه پیوسته باشد، نه یک فهرست. hreflang چیزی نیست که یکبار اصلاح شود و رها شود؛ هر قالب صفحه تازه، هر زبان تازه و هر مهاجرت، نقطه شکست تازهای میسازد. گذاشتن اعتبارسنجی داخل جریان انتشار، هم ارزانتر از ممیزی شش ماه بعد است و هم اثرگذارتر.
ما چنین پیکربندیهای اعتبارسنجی پیوستهای را بخش استاندارد کارهای سئوی فنی خود میدانیم؛ اگر بخواهید پیکربندیتان را با هم مرور کنیم، میتوانید با ما تماس بگیرید.
یک نکته پایانی درباره ترتیب کار: وقتی این دوازده خطا را پیدا کردید، سعی نکنید همه را همزمان اصلاح کنید. اول سیگنالهای متناقض (9-12) را حل کنید، بعد خطاهای کد و URL (5-8) و در آخر ساختار گروه (1-4). اگر از ترتیب معکوس پیش بروید، ساختار گروهِ اصلاحشده بهخاطر canonicalهای متناقض همچنان کار نمیکند و چنین به نظر میرسد که اصلاحی انجام نشده است.