چک‌لیست نقشهٔ سایت XML سالم؛ ۱۲ مورد قبل از انتشار

ساخت و ثبت فایل را در آموزش گام‌به‌گام ساخت نقشهٔ سایت XML سالم در آن مقاله گام‌به‌گام خواندید؛ این مقاله گام قبل از انتشار را جلوی شما می‌گذارد، جایی که بیشتر خطاها بذر می‌گیرند و ماه‌ها بی‌سروصدا بزرگ می‌شوند. منطق چک‌لیست ساده است: فایل نقشهٔ سایت فقط یک کار می‌کند — اعلام «این آدرس‌ها مهم و تازه‌اند» به ربات — پس هر موردی که این پیام را مخدوش کند، از فایل حذف می‌شود.

چرا چک‌لیست جدا؟ چون فایل نقشهٔ سایت معمولاً یک بار ساخته می‌شود و ماه‌ها فراموش می‌شود: آدرس‌های ریدایرکت‌شده در آن می‌مانند، تاریخ‌ها کهنه می‌شوند و فایل کم‌کم از ویترین به آرشیو تبدیل می‌شود. دوازده مورد این فهرست از ممیزی‌های مکرر ما روی دامنه‌های فارسی انتخاب شده‌اند؛ نقشهٔ کامل مقاله‌های این حوزه در هاب سئو فنی مرتب است و موردی که در این فهرست نیست به احتمال کم اثرگذار است، نه بی‌اثر.

نقشهٔ سایت XML سالم چرا قبل از انتشار باید چک شود؟

فایل نقشهٔ سایت، فهرست رسمی شماست که می‌گوید کدام آدرس‌ها ارزش خزش فوری دارند؛ ربات در روزهای شلوغ همین نقشهٔ کوتاه را راهنمای خود می‌کند. اگر این فهرست آدرس‌های تکراری، ریدایرکت‌شده یا صفحات کم‌ارزش را هم داشته باشد، پیام مخدوش می‌فرستد و اعتماد ربات به فایل سرد می‌شود. چک قبل از انتشار یعنی همین پیام را یک بار، پیش از مواجهه با ربات، تمیز کنیم.

زمان این چک هم مشخص است: بعد از مهاجرت دامنه یا قالب، بعد از تغییر ساختار آدرس‌ها، بعد از حذف گروهی از محصولات و هر سه ماه یک‌بار به‌عنوان روال ثابت. در این نقاط احتمال باقی‌ماندن آدرس‌های مرده در فایل اوج می‌گیرد و همان‌جاست که چک پنج‌دقیقه‌ای این مقاله، ارزان‌ترین بیمهٔ فنی سال شماست.

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

گروه اول؛ دسترس‌پذیری و فرمت فایل

مورد یک، دسترس‌پذیری عمومی: آدرس فایل باید بدون ورود و بدون ریدایرکت، مستقیم از مرورگر باز شود و کد ۲۰۰ برگرداند؛ فایلی که خودش ریدایرکت می‌کند، اولین حلقهٔ زنجیره را شل می‌کند. مورد دو، فرمت درست: فایل باید XML معتبر باشد، بدون تگ ناقص و بدون کاراکتر بازنشانه‌گذاری‌نشده؛ خروجی افزونه را یک بار در مرورگر باز کنید و مطمئن شوید خطای قرمز نمی‌گیرید. مورد سه، محل درست: فایل در ریشهٔ دامنه باشد؛ گوگل قاعدهٔ محل فایل را در مستندات robots مشخص کرده و هر فایل را در حوزهٔ خودش می‌خواند (تاریخ گردآوری: آبان ۱۴۰۵).

دو چک فرعی همین گروه: حجم فایل را در سقف پروتکل نگه دارید و اگر سایت بزرگید، فایل را به چند ایندکس نقشه تقسیم کنید تا هر بخش جداگانه قابل پایش باشد. تقسیم بی‌دلیل هم نکنید؛ هر قطعه باید معنای مدیریتی داشته باشد — محصولات، مقالات، دسته‌ها — نه تقسیم تصادفی برای رد شدن از چک. به تجربهٔ ما همین تفکیک معنایی است که بعداً در گزارش پوشش، سراغ منبع خطا را کوتاه می‌کند و جلسهٔ عیب‌یابی را از حدس به گزارش می‌رساند.

گروه دوم؛ آدرس‌های داخل فایل

مورد چهار، کانونی‌بودن: فقط آدرس کانونی هر صفحه در فایل باشد؛ نسخهٔ با پارامتر و نسخهٔ بدون پارامتر کنار هم یعنی اعلام نسخه‌های رقیب. مورد پنج، ایندکس‌پذیری: صفحاتی که با noindex بسته شده‌اند نباید در فایل باشند؛ یادتان باشد مسدودکردن با robots.txt خزش را می‌بندد نه ایندکس را، پس ابزار پنهان‌کردن صفحه از فایل نیست و چیدمان این دو را در نوشتن robots.txt درست جدا نوشته‌ایم (تاریخ گردآوری: آبان ۱۴۰۵). مورد شش، حذف مرده‌ها: ریدایرکت‌ها، خطای ۴۰۴ و آدرس‌های خالی از فایل بیرون بیایند؛ فایل آرشیو نیست، ویترین است.

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

گروه سوم؛ به‌روزرسانی و lastmod

مورد هفت، صداقت lastmod: تاریخ آخرین تغییر واقعی محتوا باشد، نه تاریخ تولید فایل؛ همهٔ آدرس‌ها با یک تاریخ مشترک، این سیگنال را بی‌ارزش می‌کند و رباتی که چند بار دروغ آن را دیده، به کل فایل بی‌اعتماد می‌شود. مورد هشت، هم‌زمانی با انتشار: صفحهٔ تازه همان روز انتشار به فایل برسد و صفحهٔ حذف‌شده همان روز از آن بیرون بیاید؛ فاصلهٔ این دو، دقیقاً همان چیزی است که فایل را از حالت سالانه به حالت زنده می‌برد. مورد نه، پایداری ساختار: نام فایل و آدرسش ثابت بماند تا تاریخچهٔ پایش قابل مقایسه باشد؛ هر جابه‌جایی یک شکست در روند گزارش است.

به تجربهٔ ما خطای lastmod شایع‌تر از همه است، چون افزونه‌ها به‌سادگی تاریخ امروز را برای همه می‌گذارند. راه‌چک ما پنج‌دقیقه‌ای است: خروجی را با چند صفحهٔ شناخته‌شده مقایسه کنید؛ اگر تاریخ صفحه‌ای که دو سال تغییر نکرده با صفحهٔ دیروز یکی است، تنظیم افزونه را همان روز درست کنید. این پنج دقیقه، اعتبار کل فایل را نجات می‌دهد.

گروه چهارم؛ ثبت، پایش و سقف‌های پروتکل

مورد ده، ثبت رسمی: فایل در بخش نقشه‌های سایت سرچ‌کنسول ثبت شود و خط Sitemap در robots.txt با آدرس مطلق نوشته شود، نه آدرس نسبی؛ گوگل در مستندات خود صراحتاً آدرس مطلق را خواسته است (تاریخ گردآوری: آبان ۱۴۰۵). مراحل ثبت و چرخهٔ پایش را در ثبت و پایش نقشهٔ سایت XML با جزئیات نوشته‌ایم. مورد یازده، پایش منظم: گزارش پوشش را برای خطاهای نو ببینید؛ جهش خطا معمولاً مقدمهٔ افت ایندکس است، نه پیامد آن. مورد دوازده، هم‌سویی با هاب: صفحاتی که در فایل اعلام می‌کنید مهم‌اند باید از منو و هاب‌ها هم لینک بخورند؛ فایل جایگزین معماری لینک نیست، مکمل آن است.

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

خطاهای پرتکراری که این چک‌لیست می‌بندد

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

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

برای تیم‌های کوچک، این کار در یک ساعت جمع می‌شود: بیست دقیقه پاک‌سازی آدرس‌های مرده، بیست دقیقه تطبیق کانونی‌ها با خروجی سامانه، ده دقیقه اصلاح تاریخ‌ها و ده دقیقه ثبت در سرچ‌کنسول. اگر یکی از این بلوک‌ها برایتان طولانی شد، همان بلوک نشانهٔ بزرگ‌تربودن مشکل است.

جمع‌بندی؛ از چک‌لیست تا انتشار امن

دوازده مورد را در چهار گروه جمع کنید: فایل باز و بدون خطا در ریشهٔ دامنه؛ فقط آدرس‌های کانونی و ایندکس‌پذیر؛ lastmod صادقانه و هم‌زمان با انتشار؛ ثبت در سرچ‌کنسول و پایش منظم با چهار سنجه. این چک پنج‌دقیقه‌ای را به گیت انتشار هر مهاجرت و هر بازطراحی تبدیل کنید؛ در تیم ما هیچ بازطراحی بدون همین گیت تحویل نمی‌شود، چون ارزان‌ترین کنترل کیفی فنی همین پنج دقیقه است و جبران غفلت از آن، ماه‌ها زمان می‌برد.

اگر خواستید به‌روزرسانی فایل و انتشار را به روال ثابت بسپارید، امکانات انتشار و رصد سوئیت را ببینید و پیش از تغییرات فنی بزرگ، وضع فعلی دامنه را با ممیزی رایگان دامنه بسنجید؛ نقشهٔ سایت سالم اولین ردیف گزارش ماست. نقشهٔ سایت XML سالم مقصد نیست، روال است؛ روالی که هر سه ماه یک بار تکرار شود، سایت را از فایل‌های فراموش‌شده دور نگه می‌دارد و سهم فنی سئو را از حدس به گزارش می‌رساند.

رصد ما، رشد شما.