مهاجرت سایت بدون افت سئو؛ چک‌لیست فنی برای URL، محتوا، Redirect و Indexing

مهاجرت سایت کار دامنه نیست؛ کار قرارداد URL است. گوگل صفحه را با آدرس می‌شناسد، نه با حس تیم که «محتوا همان است». اگر آدرس قدیمی به مقصد دقیق نرسد، سیگنال ایندکس، لینک داخلی و سابقهٔ خزیدن از هم جدا می‌شود. افت ترافیک بعد از مهاجرت معمولاً از طراحی جدید نمی‌آید؛ از URL گم‌شده، ریدایرکت زنجیره‌ای، canonical متناقض و sitemap که هنوز آدرس مرده را تبلیغ می‌کند می‌آید.

این متن چک‌لیست اپراتوری است. وعدهٔ رتبه نمی‌دهد و عدد ساختگی از کمپین‌های فرضی نمی‌سازد. هدف این است که قبل از cutover بدانید چه چیزی باید پایدار بماند، روز مهاجرت چه چیزی باید سبز باشد، و سی روز بعد چه چیزی را در Search Console باید بسته‌اید.

چرا مهاجرت سئو را می‌شکند، حتی وقتی ظاهر سایت بهتر شده

تیم‌ها مهاجرت را با بیلد، دیزاین و هاست یکی می‌گیرند. موتور جست‌وجو با چهار چیز کار می‌کند: URL، محتوا، ارجاع (ریدایرکت و لینک)، و سیگنال ایندکس. اگر هر کدام از این چهار لایه در مقصد با مبدأ هم‌خوان نباشد، گوگل باید صفحه را دوباره کشف، تفسیر و اعتماد کند. این فرآیند زمان می‌برد و در این فاصله ممکن است صفحه از نتایج موقت کنار برود یا با نسخهٔ اشتباه ایندکس شود.

خطاهای تکراری را با اسم بشناسید. ریدایرکت همهٔ مسیرها به صفحهٔ اصلی، تغییر اسلاگ بدون جدول نگاشت، دو نسخهٔ www و غیرwww که هر دو ۲۰۰ می‌دهند، پارامترهای فیلتر که ایندکس می‌شوند، و canonical که به URL قدیمی اشاره می‌کند در حالی که ریدایرکت به URL جدید است. هیچ‌کدام از این‌ها با «سایت سریع‌تر شده» جبران نمی‌شوند.

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

قبل از جابه‌جایی: موجودی URL را مثل دارایی مالی ثبت کنید

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

برای هر URL این فیلدها را نگه دارید: آدرس مبدأ، وضعیت فعلی (۲۰۰، ۳۰۰، ۴۰۴)، نوع صفحه (خانه، دسته، محصول، مقاله، فیلتر، تگ، نویسنده، جست‌وجو)، عنوان و H1، canonical فعلی، و تصمیم مقصد (حفظ اسلاگ، ادغام، حذف، noindex). صفحه‌ای که باید حذف شود هم تصمیم می‌خواهد: ریدایرکت به نزدیک‌ترین جایگزین معنادار، یا ۴۱۰ اگر واقعاً وجود ندارد و نباید جایگزین مصنوعی بسازید.

موجودی را با crawl تأیید کنید، نه فقط با خروجی CMS. افزونه‌ها، آرشیو تاریخ، پیجینیشن و پارامتر utm گاهی URLهایی می‌سازند که در پنل وردپرس دیده نمی‌شوند اما در ایندکس هستند. اگر این آدرس‌ها را نبیند، بعد از مهاجرت به‌صورت ۴۰۴ ظاهر می‌شوند و بودجهٔ خزش را روی خطای مرده خرج می‌کنند.

نگاشت URL به URL؛ الگو کافی نیست، استثنا قانون است

یک قانون کلی مثل «همهٔ /product/ به /p/» فقط نقطهٔ شروع است. فروشگاه و مجله تقریباً همیشه استثنا دارند: اسلاگ فارسی با نیم‌فاصله، محصول حذف‌شده، دستهٔ ادغام‌شده، مقالهٔ تکراری، و صفحهٔ فرود کمپین که اسلاگ بازاری دارد نه اسلاگ فنی. نگاشت باید ردیفی باشد؛ هر مبدأ یک مقصد نهایی. مقصد نهایی یعنی URLی که خود ۲۰۰ است و دیگر ریدایرکت نمی‌شود.

قبل از cutover، روی محیط staging همان نگاشت را تست کنید. درخواست HEAD یا GET به مبدأ باید به مقصد نهایی برسد، با کمترین پرش. زنجیرهٔ /old به /tmp به /new را از الان باز کنید. گوگل زنجیره را دنبال می‌کند، اما هر پرش اضافه نقطهٔ شکست، کش اشتباه و تفسیر ضعیف‌تر از انتقال سیگنال است. مستندات ریدایرکت‌ها در Google Search Central تأکید می‌کنند ریدایرکت باید به صفحهٔ معادل یا نزدیک‌ترین جایگزین برود، نه به یک صفحهٔ عمومی که فقط «چیزی» نشان می‌دهد.

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

ریدایرکت ۳۰۱ قرارداد دائمی است، نه وصلهٔ هفتهٔ اول

برای جابه‌جایی دائمی مسیر، ریدایرکت ۳۰۱ همان قراردادی است که به خزنده می‌گوید مقصد جدید نسخهٔ معتبر است. ریدایرکت ۳۰۲ یا متارفرش برای مهاجرت پایدار مناسب نیست؛ سیگنال موقت می‌فرستد. جاوااسکریپت‌ریدایرکت را به‌عنوان مکانیزم اصلی مهاجرت به کار نبرید. اگر کاربر باید قبل از رسیدن به محتوا کلاینت را اجرا کند، خزنده و کاربر هر دو مسیر شکننده‌تری دارند.

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

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

مدت نگه‌داری ریدایرکت را کوتاه نکنید. تا وقتی لینک خارجی، sitemap قدیمی در کش، یا کمپین چاپی به مبدأ می‌رسد، ۳۰۱ باید زنده بماند. برداشتن زودهنگام ریدایرکت یعنی بازگرداندن ۴۰۴ به آدرسی که گوگل هنوز ممکن است در ایندکس داشته باشد.

Canonical، نسخهٔ ترجیحی دامنه و پارامترها را قبل از ترافیک واقعی قفل کنید

ریدایرکت بدون canonical منسجم، نیمهٔ کار است. نسخهٔ ترجیحی را یک‌بار تصمیم بگیرید: https در برابر http، www در برابر بدون www، اسلش پایانی در برابر بدون اسلش، و حروف کوچک در اسلاگ انگلیسی. هر دو نسخه نباید ۲۰۰ بدهند. یکی ریدایرکت شود، دیگری canonical خود را به خودش بدهد.

پارامترهای مرتب‌سازی، موجودی و فیلتر را از ایندکس خارج کنید مگر صفحهٔ فیلتر ارزش مستقل جست‌وجو داشته باشد. اگر /category/shoes?color=black و /category/black-shoes هر دو ایندکس شوند، خودتان cannibalization ساخته‌اید. Canonical باید به نسخهٔ تمیز اشاره کند؛ robots و پارامتر Search Console مکمل‌اند نه جایگزین تصمیم معماری.

در مقصد جدید، تگ canonical را از روی مسیر واقعی درخواست بسازید، نه از یک ثابت اشتباه در قالب. در Next.js این کار با alternates.canonical در Metadata API انجام می‌شود؛ جزئیات پیاده‌سازی در مستندات metadata و تصویر Open Graph آمده است. اگر canonical به دامنهٔ قدیم، به HTTP، یا به صفحه‌ای که خودش ریدایرکت است اشاره کند، خزنده بین سیگنال‌ها گیر می‌کند.

محتوا، متادیتا و دادهٔ ساختاریافته باید با URL جدید سفر کنند

حفظ URL بدون حفظ معنا ناقص است. H1، عنوان متا، توضیحات، و بدنه باید معادل یا بهتر از مبدأ باشند؛ نه اینکه قالب جدید فیلدها را خالی بگذارد چون «بعداً پر می‌کنیم». صفحهٔ محصول بدون عنوان و بدون دادهٔ مشخصات، از نظر ایندکس صفحهٔ ضعیف است حتی اگر اسلاگ همان باشد.

دادهٔ ساختاریافته را از مبدأ به مقصد منتقل کنید و با URL جدید هم‌خوان کنید. نوع‌های رایج فروشگاه و مجله در Schema.org تعریف شده‌اند: Product، Offer، BreadcrumbList، Article، Organization. اگر JSON-LD هنوز @id یا url دامنهٔ قدیم را دارد، شما به گوگل دو هویت برای یک موجودیت داده‌اید. بعد از مهاجرت، نمونهٔ صفحه را با ابزار تست دادهٔ ساختاریافته بررسی کنید؛ خطا را مثل باگ بیلد ببندید.

تصاویر را هم در موجودی ببینید. اگر CDN و مسیر فایل عوض شده، src قدیمی ۴۰۴ می‌شود و صفحه از نظر کیفیت و تصاویر گوگل ضعیف‌تر دیده می‌شود. ریدایرکت تصویر یا حفظ مسیر عمومی فایل، جزئی از مهاجرت سئو است نه کار جداگانهٔ دیزاین.

ایندکس بعد از Cutover: sitemap، Search Console و بودجهٔ خزش

روز مهاجرت، sitemap جدید فقط URLهای ۲۰۰ نهایی را فهرست کند. URL ریدایرکت‌شده، ۴۰۴ و noindex را از sitemap حذف کنید. گوگل sitemap را دستور نمی‌داند، اما آن را نشانهٔ اولویت می‌گیرد. اگر sitemap هنوز اسلاگ قدیم را تبلیغ کند، خزنده را به عمد به مسیر انتقال می‌فرستید.

در Search Console دامنهٔ مبدأ و مقصد را پوشش دهید. اگر دامنه عوض شده، از ابزار تغییر آدرس فقط وقتی استفاده کنید که شرایط آن برقرار است؛ برای مهاجرت مسیر داخل همان دامنه، تمرکز روی ریدایرکت، sitemap و درخواست ایندکس صفحات کلیدی است. صفحات پول‌ساز و صفحات ستون محتوا را بعد از ۲۰۰ شدن، برای خزش علامت بزنید. بقیه را به کشف طبیعی و لینک داخلی بسپارید؛ هجوم درخواست ایندکس برای هزاران فیلتر کمکی نمی‌کند.

گزارش‌هایی که باید در هفتهٔ اول و ماه اول نگاه کنید: پوشش ایندکس (چرا صفحات جدید excluded شده‌اند)، ۴۰۴، ریدایرکت، و تجربهٔ صفحه اگر Core Web Vitals تحت تأثیر بیلد جدید است. افت موقت کشف طبیعی است؛ افت پایدار وقتی است که ۴۰۴ و canonical اشتباه در گزارش‌ها انباشته می‌شوند و شما آن را به «الگوریتم» نسبت می‌دهید.

اگر مهاجرت از وردپرس به اپلیکیشن React/Next است، ریسک ایندکس دو لایه دارد: قرارداد URL و نحوهٔ رندر HTML. مسیر فنی تعویض پلتفرم را در چارچوب مهاجرت وردپرس به Next.js جدا دنبال کنید تا چک‌لیست سئو این مقاله با تصمیم‌های بیلد قاطی نشود.

نمونهٔ عملی: فروشگاه Next.js که کاتالوگ و محتوا باید پایدار بماند

فرض کنید فروشگاهی مثل فراسیب را جابه‌جا می‌کنید؛ فروشگاه Next.js با کاتالوگ اشتراک و محتوا، نه یک ویترین ایستا. اینجا مهاجرت موفق یعنی مسیر دسته، محصول و مقاله تا جای ممکن همان بماند. کاربر و خزنده هر دو با اسلاگ کاتالوگ زندگی می‌کنند. اگر /product/some-slug به /items/some-slug عوض شود فقط به‌خاطر «ساختار تمیزتر»، شما هزینهٔ ریدایرکت و ریسک از دست رفتن اسنیپت را برای سلیقهٔ مهندسی خریده‌اید.

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

در چنین فروشگاهی دو خانواده URL حیاتی‌اند: کاتالوگ تراکنشی و محتوای کمکی (راهنما، سوالات، سیاست‌ها). اگر محتوا به ساب‌مسیر جدید برود و کاتالوگ در جای خود بماند، باز هم نگاشت جدا لازم است. ادغام بی‌قاعدهٔ مقاله در صفحهٔ محصول، یا برعکس، هم تجربه را خراب می‌کند هم سیگنال موضوعی را. رتبهٔ فرضی برای این مثال نمی‌سازیم؛ معیار موفقیت عملیاتی است: مبدأ به مقصد معادل می‌رسد، ایندکس پوشش کاتالوگ را از دست نمی‌دهد، و ۴۰۴ کاتالوگ در Search Console بالا نمی‌رود.

چک‌لیست روز مهاجرت و سی روز بعد

روز مهاجرت را مثل استقرار دیتابیس اجرا کنید، نه مثل رونمایی دیزاین. قبل از تغییر DNS یا سوییچ ترافیک: HTTPS روی مقصد، نسخهٔ دامنهٔ ترجیحی، جدول ریدایرکت روی لبه، robots مجاز برای خزش (مگر محیط استیجینگ)، sitemap نهایی، و چند URL نمونه از هر قالب صفحه که ۲۰۰ هستند و canonical خود را دارند. صفحهٔ خانه تنها نمونهٔ کافی نیست. یک محصول، یک دسته، یک مقاله، یک صفحهٔ فیلتر و یک ۴۰۴ عمدی را تست کنید.

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

سی روز بعد سه سوال بپرسید. آیا صفحات کلیدی مقصد ایندکس شده‌اند؟ آیا مبدأ هنوز در نتایج با URL قدیم ظاهر می‌شود و به مقصد ۳۰۱ می‌شود؟ آیا پوشش excluded به‌خاطر duplicate، canonical یا soft 404 بالا رفته؟ اگر پاسخ‌ها روشن نباشد، مهاجرت تمام نشده؛ فقط دیزاین عوض شده است.

پرسش‌های متداول

آیا ۳۰۱ کافی است تا رتبه حفظ شود؟

ریدایرکت ۳۰۱ قوی‌ترین سیگنال انتقال آدرس است، اما رتبه را تضمین نمی‌کند. محتوا، لینک داخلی، کیفیت صفحه و ایندکس مقصد باید معادل یا بهتر باشند. ۳۰۱ بدون صفحهٔ معادل، فقط کاربر را به جای دیگری می‌برد.

تفاوت canonical و ریدایرکت در مهاجرت چیست؟

ریدایرکت وقتی است که URL قدیم دیگر نباید ۲۰۰ بدهد. Canonical وقتی است که چند URL زنده یک محتوا را نشان می‌دهند و یکی نسخهٔ ترجیحی است. در مهاجرت مسیر، اول ریدایرکت مبدأ به مقصد نهایی را بگذارید؛ canonical را روی مقصد نهایی به خودش تنظیم کنید.

Sitemap را چه زمانی عوض کنیم؟

همزمان با سوییچ ترافیک. sitemap باید فقط URLهای نهایی ۲۰۰ را داشته باشد. نگهداری همزمان اسلاگ قدیم و جدید در یک فایل، خزنده را به مسیرهای در حال انتقال دعوت می‌کند.

اگر محصول حذف شده و جایگزین ندارد چه کنیم؟

به خانه ریدایرکت نکنید. اگر دستهٔ والد هنوز معنا دارد، به همان دسته. اگر موجودیت واقعاً مرده است، ۴۱۰ یا ۴۰۴ پایدار بهتر از صفحهٔ بی‌ربط است. گوگل صفحهٔ بی‌ربط را انتقال سیگنال نمی‌فهمد.

مهاجرت سایت بدون افت سئو یعنی موجودی، نگاشت، ۳۰۱، canonical و ایندکس را مثل یک سیستم واحد مدیریت کنید. اگر این پنج لایه هم‌خط باشند، تغییر CMS یا دیزاین می‌تواند بدون پاک کردن سابقهٔ URL انجام شود. قدم بعدی این است که جدول نگاشت را قبل از بیلد نهایی قفل کنید؛ نه بعد از رونمایی.