ساخت سایت مپ و robots.txt؛ تصمیم هماهنگ برای آدرس‌های سایت

ساخت سایت مپ و robots.txt زمانی مفید است که پیش از آن درباره نقش آدرس‌ها تصمیم گرفته باشید. باید بدانید کدام صفحه عمومی و قابل جست‌وجو است، کدام مسیر برای عملیات کاربر ساخته شده و کدام آدرس نسخه قدیمی محتواست. تولید خودکار فایل بدون این تصمیم‌ها می‌تواند فقط فهرستی مرتب از آدرس‌های نامناسب بسازد. canonical نیز باید با همین سیاست هماهنگ باشد. هدف، رساندن نشانه‌های سازگار درباره نسخه درست هر محتواست، نه جمع کردن چند فایل برای تکمیل ظاهری پروژه.

نقشه سایت را از صفحات قابل انتشار بسازید

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

زمان تغییر را واقعی نگه دارید

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

robots.txt ابزار کنترل دسترسی نیست

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

canonical را با لینک‌ها هماهنگ کنید

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

مثال فرضی: تغییر دامنه محیط آزمایش

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

چک‌لیست تحویل

• دامنه اصلی و سیاست نسخه‌های آدرس مشخص است.
• sitemap فقط آدرس‌های مطلوب و سالم را معرفی می‌کند.
• lastmod، در صورت وجود، زمان تغییر معنادار است.
• robots با سیاست خزش هماهنگ است و نقش امنیتی ندارد.
• canonical، لینک داخلی و نقشه سایت سازگارند.
• تغییر محیط و انتشار بعدی دوباره بررسی می‌شود.

برای تصویر کامل‌تر، سئو تکنیکال سایت و کاهش ریسک انتقال سایت را ببینید. این موارد در طراحی سایت شرکتی باید بخشی از تحویل فنی قابل مشاهده باشند.