یک دامنه 25 ساله خریدم؛ URLهای مرده روزی بیش از 1,000 درخواست می‌گرفتند

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

URLهایی که اصلاً در پروژه جدید وجود نداشتند، روزانه بیش از 1,000 درخواست دریافت می‌کردند. در analytics این موضوع به شکل جهش بزرگ direct traffic با engagement تقریباً صفر دیده می‌شد. هم‌زمان crawler یاندکس دوباره به pathهای قدیمی سر می‌زد، 404 Not Found می‌گرفت و Yandex Webmaster در یک شب بیش از 900 خطا ثبت کرد.

توضیح اولیه من ساده بود: بات‌های قدیمی URLهای مرده را می‌زنند، Yandex این فعالیت را می‌بیند و به همین دلیل crawl را ادامه می‌دهد. از زاویه دید من، ترتیب اتفاق‌ها همین‌طور به نظر می‌رسید. اما داده‌های من برای اثبات این رابطه علّی کافی نبود.

چیزهایی که واقعاً می‌توانستم تأیید کنم

سه مشاهده جداگانه وجود داشت. اول، سرور حجم زیادی درخواست برای URLهای باقی‌مانده از زندگی قبلی دامنه دریافت می‌کرد. دوم، این ترافیک تقریباً هیچ engagement واقعی از کاربر ایجاد نمی‌کرد. سوم، crawler یاندکس نیز pathهای قدیمی را درخواست می‌کرد و داشبورد Webmaster در یک شب بیش از 900 خطا نشان داد.

از نظر عملیاتی این یک مشکل واقعی بود: لاگ‌های شلوغ، درخواست‌های غیرضروری و گزارش خطایی که باید تمیز می‌شد. اما این واقعیت‌ها ثابت نمی‌کنند که بات‌های شخص ثالث باعث crawl یاندکس شده‌اند یا خطاها مستقیماً ranking یا organic traffic را کاهش داده‌اند. Crawling با indexing یکی نیست، indexing با ranking یکی نیست و گزارش خطا مدرک penalty نیست.

بخشی از 404 و 410 که بیش از حد ساده کرده بودم

قبلاً این تفاوت را تقریباً این‌طور می‌دیدم: 404 یعنی «شاید فعلاً نیست» و 410 یعنی «برای همیشه حذف شده». به‌عنوان یک مدل ذهنی مفید است، اما از نظر فنی دقیق نیست.

404 Not Found یعنی سرور نمی‌تواند representation فعلی resource درخواستی را ارائه کند؛ خود status مشخص نمی‌کند این وضعیت موقت است یا دائمی. 410 Gone مشخص‌تر است: وقتی سرور می‌داند resource دیگر در دسترس نیست و انتظار می‌رود این وضعیت دائمی باشد، انتخاب مناسبی است.

این دقت در ادعاهای SEO هم مهم است. موتورهای جست‌وجو می‌توانند URLهایی را که 404 یا 410 برمی‌گردانند از نتایج حذف کنند. بنابراین دیگر 410 را یک «status قوی‌تر برای SEO» نمی‌نامم و 404 را هم برای همه صفحات حذف‌شده اشتباه نمی‌دانم.

چرا 410 هدفمند همچنان برای مورد من منطقی بود

pathهای قدیمی مشکل موقتی نبودند. آن‌ها متعلق به محتوای قبلی دامنه بودند و در پروژه جدید جایی نداشتند. می‌دانستم این URLهای مشخص برای همیشه از بین رفته‌اند. بنابراین 410 Gone وضعیت آن‌ها را دقیق توصیف می‌کرد.

به همین دلیل 410 را فقط برای legacy pathهای شناخته‌شده تنظیم کردم، نه اینکه هر URL ناشناخته‌ای را 410 کنم. بعد از این تغییر، نویز crawl و reporting پیرامون pathهای قدیمی کمتر شد و وضعیت ابزارهای webmaster بسیار تمیزتر شد.

با این حال درباره علیت محتاط هستم. می‌توانم بگویم بهبود بعد از این تغییر رخ داد و 410 از نظر معنایی برای آن URLها درست بود. نمی‌توانم ثابت کنم که 410 به‌تنهایی همه بات‌ها را متوقف کرد. یک بات شخص ثالث می‌تواند معنای HTTP status را نادیده بگیرد و همان path را بی‌نهایت درخواست کند.

قاعده تصمیم‌گیری من حالا

سؤال مفید این نیست که «410 بهتر از 404 است؟»؛ سؤال این است که «واقعاً چه اتفاقی برای این URL افتاده؟»

• جایگزین مشخص وجود دارد: از permanent redirect مثل 301 به URL جدید واقعاً معادل استفاده کنید.
• resource قدیمی به‌طور قطعی برای همیشه حذف شده و جایگزین ندارد: 410 Gone انتخاب دقیقی است.
• URL صرفاً ناشناخته، اشتباه تایپی یا از ابتدا ناموجود است: 404 Not Found معمولی مناسب است.

کاری که انجام نمی‌دهم redirect کردن تمام URLهای مرده به صفحه اصلی فقط برای حذف خطاهاست. این کار وضعیت واقعی resource را پنهان می‌کند و می‌تواند تجربه بدتری برای کاربر و crawler ایجاد کند.

امروز یک دامنه قدیمی را قبل از راه‌اندازی چگونه بررسی می‌کنم

اگر دوباره از دامنه‌ای با سابقه استفاده کنم، تاریخچه URLهای آن را بخشی از migration در نظر می‌گیرم، حتی اگر خود سایت قبلی را منتقل نکنم.

1. footprint قدیمی را بررسی کنید. قبل از launch به دنبال historical URLها و legacy sectionهای واضح بگردید.
2. از روز اول access log را ببینید. درخواست‌های تکراری به pathهایی که هرگز نساخته‌اید نشان می‌دهد دامنه هنوز در حافظه سیستم‌های بیرونی وجود دارد.
3. انسان‌ها، search crawlerها و بات‌های تصادفی را جدا کنید. جهش direct traffic و crawler error دو signal متفاوت‌اند و نباید خودکار به یک داستان علّی تبدیل شوند.
4. dead URLهای تکرارشونده را دسته‌بندی کنید. برای هر pattern مهم آگاهانه بین 301، 404 و 410 انتخاب کنید.
5. نتیجه را جداگانه مانیتور کنید. تعداد درخواست، crawler report و indexing ابعاد متفاوت‌اند؛ من آن‌ها را در یک معیار مبهم «SEO health» خلاصه نمی‌کنم.

این کار در مقایسه با زمانی که مشکل را بعد از پر شدن لاگ‌ها و ابزارهای webmaster از نویز پیدا کنید، بسیار کم‌هزینه است.

410 چه چیزی را حل نمی‌کند

410 یک بیان HTTP درباره وضعیت resource است. firewall، rate limiter یا مکانیزم مسدودسازی بات نیست. اگر scraper بعد از دریافت 410 همچنان درخواست بفرستد، سرور باید آن‌ها را دریافت و پاسخ دهد. اگر مشکل واقعی حجم سوءاستفاده‌گرانه درخواست‌هاست، آن یک مسئله زیرساختی جداگانه است.

همچنین SEO boost نیست. status درست به crawler کمک می‌کند بفهمد چه اتفاقی برای URL افتاده، اما به‌تنهایی باعث بهتر شدن ranking سایت جدید نمی‌شود.

درسی که برای من باقی ماند

نکته عجیب این نبود که دامنه قدیمی URLهای قدیمی داشت. عجیب این بود که این تاریخ نامرئی چقدر سریع بعد از launch دوباره ظاهر شد: روزانه بیش از 1,000 درخواست برای صفحاتی که من نداشتم، engagement تقریباً صفر و بیش از 900 خطا در Yandex Webmaster طی یک شب.

دامنه قدیمی یک namespace خالی نیست. لینک‌های قدیمی، crawlerها، scriptها و بات‌ها می‌توانند pathها را سال‌ها بعد از حذف محتوای اصلی به خاطر داشته باشند. قاعده فعلی من ساده است: تاریخچه را audit کن، HTTP status مطابق واقعیت برگردان و bot traffic عملیاتی را از نتیجه‌گیری درباره موتور جست‌وجو جدا نگه دار.

سابقه می‌تواند دارایی باشد. در عین حال stateای است که به ارث می‌برید.