پرش به محتوا
SEO Evaluate
مطالب مرتبط
سئو5 دقیقه مطالعه

معماری sitemap در سایت چندزبانه: زبان‌ها و بودجه خزش

ساخت sitemap برای سایت چندزبانه: یک فایل برای هر زبان یا یک ایندکس، انتقال hreflang به sitemap، نظم lastmod و اینکه کدام URLها بیرون می‌مانند.

نوشته Roozbeh Nazari · CEO

معماری sitemap در سایت چندزبانه: زبان‌ها و بودجه خزش

sitemap کم‌بحث‌ترین و بیشترین‌بار غلط‌ساخته‌شده‌ترین بخش سئوی فنی است. در سایت یک‌زبانه، sitemap غلط معمولاً بی‌ضرر است: Google URLها را از راه‌های دیگر هم پیدا می‌کند. اما در سایت چندزبانه، sitemap تنها سند ساختاری است که در آن می‌گویید چهار زبان چهار مجموعه URL جداگانه‌اند، کدام URL نسخه canonical کدام زبان است و چه چیزی را نمی‌خواهید ایندکس شود. این مقاله توضیح می‌دهد که معماری sitemap را در سایتی که به ترکی، انگلیسی، عربی و فارسی منتشر می‌کند چگونه ساخته‌ایم و هر تصمیم چرا گرفته شده است.

اول قواعد: محدودیت‌های پروتکل

پروتکل sitemap دو محدودیت سخت می‌گذارد: یک فایل sitemap حداکثر می‌تواند ۵۰٬۰۰۰ URL داشته باشد و حجم فشرده‌نشده آن از ۵۰ مگابایت بیشتر نشود. سایت‌های بالای این حدها ناچارند فایل را تقسیم کنند و با یک فایل ایندکس sitemap به هم بپیوندند. یک سایت شرکتی چندزبانه به‌ندرت به این حدها نزدیک می‌شود؛ سایتی با چند صد یا چند هزار URL در یک فایل جا می‌گیرد. با این حال، تصمیم به تقسیم را نه حجم، بلکه مدیریت‌پذیری می‌گیرد؛ پایین‌تر به آن می‌رسیم.

قاعده دوم از مستندات خود Google است: Google فیلدهای priority و changefreq در sitemap را نادیده می‌گیرد؛ فیلد lastmod را هم فقط زمانی به کار می‌برد که به‌طور پیوسته دقیق باشد. این یعنی نوشتن «هر صفحه هر روز تغییر می‌کند» در sitemap هیچ فایده‌ای ندارد، در حالی که نوشتن تاریخی که صفحه واقعاً تغییر کرده فایده دارد.

یک فایل یا یک فایل برای هر زبان

در سایت‌های چندزبانه کوچک و متوسط سه معماری می‌بینیم. اول، یک فایل: URLهای همه زبان‌ها در یک sitemap.xml. ساده، آسان در راه‌اندازی، بی‌مشکل تا چند هزار URL. ضعف آن این است که در Search Console نمی‌توانید نرخ ایندکس را به تفکیک زبان بخوانید؛ کل سایت در یک سطر دیده می‌شود. دوم، یک فایل برای هر زبان و یک ایندکس: sitemap-tr.xml، sitemap-en.xml، sitemap-ar.xml، sitemap-fa.xml و یک sitemap.xml که آن‌ها را فهرست می‌کند. Search Console هر فایل را جدا گزارش می‌دهد؛ می‌بینید چند درصد صفحات عربی در مقایسه با صفحات ترکی ایندکس شده‌اند. سوم، یک فایل برای هر نوع محتوا: صفحات، نوشته‌های بلاگ و خدمات در فایل‌های جدا. این مدل وقتی به کار می‌آید که بخواهید سرعت ایندکس نوشته‌های بلاگ را جدا از صفحات ثابت دنبال کنید.

ترجیح ما: تا وقتی سایت زیر چند صد URL است یک فایل، و وقتی از آن گذشت یک فایل برای هر زبان. نقطه تصمیم حجم نیست، نیاز تشخیصی است: روزی که در یک زبان مشکل ایندکس شروع می‌شود، می‌خواهید آن زبان را در فایل جداگانه‌ای ببینید. این جریان تشخیص را قدم‌به‌قدم در مقاله مشکلات ایندکس توضیح داده‌ایم؛ تقسیم sitemap اولین ابزار آن جریان است.

انتقال hreflang به sitemap

Google سه راه برای اعلام نسخه‌های زبانی و منطقه‌ای می‌پذیرد: تگ‌های link در head صفحه، هدرهای HTTP، یا ورودی‌های xhtml:link درون sitemap. تگ‌های head در سایت‌های چندزبانه رایج‌اند اما دو ضعف دارند: بلوکی می‌سازند که در هر صفحه تکرار می‌شود و حجم صفحه را بالا می‌برد، و خطای قالب یک‌باره به کل سایت سرایت می‌کند. روش sitemap این بلوک را در یک فایل جمع می‌کند و راستی‌آزمایی را آسان می‌کند: می‌توانید اعلام‌های متقابل چهار زبان را در یک فایل XML بخوانید و با اسکریپت بررسی کنید.

قاعده ساده است اما زیاد نقض می‌شود: هر ورودی URL باید همه جایگزین‌هایش، از جمله خودش، را فهرست کند و جایگزین‌ها باید متقابل باشند. اگر صفحه ترکی به نسخه عربی اشاره می‌کند، صفحه عربی هم باید به نسخه ترکی اشاره کند. برای صفحه‌ای که فقط در سه زبان وجود دارد، ورودی فقط همان سه نسخه موجود را فهرست می‌کند؛ hreflang که به صفحه‌ای ناموجود اشاره کند از پرتکرارترین خطاهایی است که می‌بینیم. فهرست کامل این خطاها و موارد مشابه در مقاله خطاهای hreflang هست. اگر sitemap و تگ‌های head را همزمان به کار می‌برید، این دو نباید با هم تناقض داشته باشند؛ در عمل، انتخاب یک روش امن‌تر است.

URLهای عربی و فارسی: کدگذاری

sitemap شکل درصدی‌کدگذاری‌شده URLها را می‌خواهد. یک URL با slug عربی یا فارسی در مرورگر خواندنی به نظر می‌رسد، اما در sitemap هر حرف آن به‌صورت شش کاراکتر کدگذاری‌شده جا می‌گیرد. این دو نتیجه دارد. اول، حجم فایل نسبت به URLهای لاتین بسیار سریع‌تر رشد می‌کند؛ به حد ۵۰ مگابایت نزدیک نمی‌شوید، اما فایل با چشم انسان ناخواندنی می‌شود و راستی‌آزمایی را باید با اسکریپت انجام دهید. دوم، slugهای بسیار طولانی عربی یا فارسی بیرون از sitemap هم مشکل می‌سازند: برخی لایه‌های سرور و کش طول URL را محدود می‌کنند. در رویه خودمان طول کدگذاری‌شده slug هر زبان را زیر ۲۴۰ کاراکتر نگه می‌داریم و این کنترل را پیش از انتشار خودکار انجام می‌دهیم.

چه چیزهایی وارد sitemap نمی‌شوند

sitemap فهرست «همه URLهای سایت» نیست، فهرست «URLهای canonical که می‌خواهم ایندکس شوند» است. این‌ها بیرون می‌مانند: URLهایی که ریدایرکت می‌شوند، URLهایی که ۴۰۴ یا ۴۱۰ برمی‌گردانند، صفحات با تگ noindex، صفحاتی که canonical آن‌ها به URL دیگری اشاره می‌کند، نسخه‌های تکراری با پارامتر یا فیلتر مرتب‌سازی، صفحاتی که ورود لازم دارند و صفحات میانی که زبان را انتخاب یا خودکار ریدایرکت می‌کنند. بودن هرکدام از این‌ها در sitemap سطرهای «URL ارسال‌شده ایندکس نشد» را در Search Console باد می‌کند و مشکلات واقعی را ناپیدا می‌سازد. پاکی sitemap، خواندنی بودن گزارش ایندکس است.

بودجه خزش: مشکل کیست

مستند بودجه خزش Google روشن است: این موضوع اساساً برای سایت‌های بسیار بزرگ یا بسیار پرتغییر مهم است. در سایت کلینیک یا آژانسی با چند هزار URL، بودجه خزش گلوگاه نیست. با این حال در سایت‌های چندزبانه کلمه بودجه را زیاد می‌شنویم، چون نشانه‌ها شبیه به نظر می‌رسند: صفحات جدید دیر ایندکس می‌شوند، برخی زبان‌ها عقب می‌مانند. علت واقعی معمولاً بودجه نیست، آشفتگی سیگنال است: تناقض‌های hreflang، خطاهای canonical، ریدایرکت خودکار زبان یا URLهای زائد در sitemap. پیش از ورود به بحث بودجه این چهار مورد را پاک کنید؛ در بیشتر موارد بحث همان‌جا تمام می‌شود.

راستی‌آزمایی و نگهداری

ساختن sitemap کار یک روز است، درست نگه داشتن آن پیوسته. سه کنترل را خودکار می‌کنیم. اول، اسکریپتی که هفتگی بررسی می‌کند هر URL در sitemap کد ۲۰۰ برمی‌گرداند و خودش را canonical نشان می‌دهد. دوم، شمارشی که تعداد URL چهار زبان را مقایسه می‌کند: اگر در ترکی ۶۰ نوشته هست و در فارسی ۴۰ دیده می‌شود، ترجمه ۲۰ نوشته ناقص یا منتشرنشده است؛ این شمارش ممیزی عملیات محتوا هم هست. سوم، کنترل ماهانه اینکه گزارش sitemap در Search Console برای هر فایل زبان در وضعیت «موفق» است و تعداد URL کشف‌شده با تعداد درون فایل برابر است. همه این سه کنترل در چک‌لیست ممیزی سئوی فنی ما قرار دارند.

یک نکته آخر: اطلاع دادن sitemap به Google با «ping» دیگر لازم نیست؛ آن نقطه پایانی از رده خارج شده است. sitemap را یک بار به Search Console بفرستید و در robots.txt با سطر Sitemap به آن اشاره کنید؛ پس از آن همه چیز به نظم lastmod بستگی دارد. اینکه sitemap در سایت‌های چندزبانه چگونه ساخته می‌شود، از موضوع‌هایی است که در هفته اول خدمت سئوی فنی به آن می‌پردازیم؛ چون هر بحث ایندکس بعدی به درستی این فایل تکیه دارد.

منابع

// تماس

بریف خود را بفرستید. بریف خود را برای ما بفرستید.

تماس آشنایی ما رایگان است. وقتی بریف شما به دستمان رسید، فرصت بازار و مهم‌ترین فرصت‌های رشد اولویت‌دار شما را نقشه‌برداری می‌کنیم.