پاسخ کوتاه: رتبه در مهاجرت از سه جا میرود: آدرسی که بدون ریدایرکت عوض شده، صفحهای که 500 میدهد بهجای 404، و نقشهی سایتی که صفحههای جدید را ندارد. ما هر سه را در مهاجرت سایت خودمان دیدیم، دو تا را قبل از راهاندازی گرفتیم و یکی را در کرال آخر. چکلیست زیر همان است، به ترتیب اجرا.
زمینه
idepoo.com از 1398 روی ASP.NET بود با حدود هشتاد آدرس شناختهشده در سرچ کنسول: صفحههای خدمات، نمونهکار با سه نوع آدرس فیلتر (دسته، برچسب، تکنولوژی)، دستههای بلاگ، و چند آدرس قدیمیتر. نسخهی جدید روی Next.js و Payload CMS، با ساختار آدرس تازه برای بیشتر صفحهها. سرچ کنسول 18 صفحهی ایندکسشده و 24 ایندکسنشده نشان میداد، و بیشترِ نمایشها روی دو آدرس بود: صفحهی اصلی و صفحهی «طراحی سایت در تهران».
چکلیست
1. فهرست کامل آدرسهای قدیم، از سه منبع
سرچ کنسول (Performance → Pages و Coverage)، نقشهی سایت قدیم، و کد سایت قدیم. سومی را بیشتر مهاجرتها جا میاندازند و ما هم نزدیک بود: روتهای کنترلرهای ASP.NET دوازده آدرس داشت که در هیچ نقشهای نبود ولی گوگل میشناخت (/Contact-Us، /workwithus، /help/order-guide، /index.html).
2. نقشهی آدرس: هر آدرس قدیم به یک مقصد
برای هر آدرس یکی از سه تصمیم: همان آدرس میماند؛ ریدایرکت 301 به آدرس جدید؛ یا 404 چون معادلی ندارد (و آن هم تصمیم است، نه فراموشی). آدرسهای فیلتر، 90 تا دسته/برچسب/تکنولوژی، همه به هاب نمونهکارها. دستههای بلاگ به هاب بلاگ. آدرسهایی که نمایش داشتند، تکتک به صفحهی همقصد.
3. ریدایرکتها در سایت جدید، قبل از راهاندازی
139 ردیف در جدول Redirects سایت جدید، تستشده با یک اسکریپت که هر آدرس قدیم را میزند و انتظار 301 به مقصد درست را دارد، نه 302، نه زنجیره، نه 200 روی صفحهی خطا. یک نکته که گیرمان انداخت: میانافزار ریدایرکت، آدرسهای نقطهدار را رد میکرد تا فایلهای استاتیک هزینهی جستوجو ندهند، و /index.html با همین قاعده 404 میماند. راهحل: آن یکی را در تنظیمات بیلد ریدایرکت کردیم.
4. 404 باید 404 باشد، نه 500
این را در بیلد تولید فهمیدیم، نه در dev. مسیر صفحههای CMS قبل از اعلام 404، هدر درخواست را میخواند تا ارجاعدهندهی لینک شکسته را ثبت کند، و در بیلد تولید، خواندن هدر داخل مسیر استاتیک خطا میدهد. نتیجه: هر آدرس ناشناخته 500 میداد. گوگل 500 را «قطعی سرور» میخواند و بعد از چند بار، کرال را کم میکند؛ پنج آدرسی که سرچ کنسول بهعنوان 404 میشناخت، بعد از راهاندازی به خطای سرور تبدیل میشد. قاعده: کرال نهایی را روی بیلد تولید بزنید، نه dev.
5. نقشهی سایت را از خودِ داده بسازید و بعد بشمارید
نقشهی سایت ما از CMS ساخته میشود، پس «همهچیز خودکار داخلش است». بود، جز چهارده نمونهکار، به خاطر یک ورودی کش که از قبل از انتشارشان مانده بود. اگر نشمرده بودیم (انتظار: 78، دیدیم: 50) نمیفهمیدیم. بشمارید و با فهرست صفحههای منتشرشده مقایسه کنید.
6. عنوان، توضیحات و canonical هر صفحهی مهم
صفحههایی که نمایش دارند، عنوان و توضیحاتشان را عمداً نزدیک به قبل نگه دارید، تغییر آدرس و تغییر عنوان با هم، دو سیگنال همزمان است. canonical هر صفحه به خودش، hreflang فقط برای صفحههایی که واقعاً ترجمه دارند.
7. روز راهاندازی در سرچ کنسول
- نقشهی جدید را ثبت کنید، قدیمی را حذف.
- URL Inspection → Request indexing روی آدرسهایی که نمایش داشتند و آدرسهای جدیدی که مهماند، سهمیهی روزانه محدود است، دو روز طول میکشد.
- Removals روی صفحههایی که نباید میبودند (صفحهی خطای سایت قدیم ما ایندکس شده بود).
- Coverage را دو هفته روزانه ببینید: «Page with redirect» بالا میرود و طبیعی است؛ «Server error» باید صفر بماند.
سه چیزی که غلط از آب درآمد
- پربازدیدترین صفحهی قدیم را ریدایرکت کرده بودیم. «طراحی سایت در تهران» 1,649 نمایش داشت و در نتایج واقعی صفحهی اول بود؛ در نقشهی اولیه به صفحهی اصلی میرفت. قبل از ریدایرکتکردن هر صفحه، در گوگل جستوجویش کنید، اگر هست، آدرس را نگه دارید و صفحه را بازسازی کنید.
- dev دروغ میگوید. باگ 500 فقط در بیلد تولید ظاهر شد. کرال آخر روی همان چیزی که مستقر میشود.
- «خودکار» یعنی بشمارید. نقشهی سایت خودکار، 14 صفحه کم داشت.
برای مشتریهای ما
همین چکلیست جزو تحویل هر پروژهی مهاجرت است، زرشاپ با بیش از پنج هزار محصول همینطور منتقل شد. اگر سایت قدیمی دارید و میخواهید بدون افت رتبه به سایت جدید برسید، فرایند کار مرحلهی انتشار را با همین بندها دارد؛ و چرا سایت شما در گوگل نیست هشت علت فنی رایج بعد از مهاجرت را میگوید.
دیدگاهها
هنوز دیدگاهی ثبت نشده است؛ اولین نفر باشید.