مهاجرت سئو و تغییر دامنه؛ بدون اینکه مسیر رشد جا بمونه
تغییر دامنه، CMS یا ساختار URL فقط یک جابهجایی فنی نیست. اگر هر صفحه مقصد درست نداشته باشه، Canonicalها ناهماهنگ باشن یا نسخه جدید بدون QA منتشر بشه، بخشی از اعتبار و ورودی سایت در مسیر انتقال گم میشه. کمپینو مهاجرت را قبل، حین و بعد از انتشار کنترل میکنه.
- نقشه URL به URL
- QA قبل و بعد از انتشار
- پایش ایندکس و ترافیک
/old-category/←/new-category//product-a/←/products/product-a//expired-page/←removedظاهر سایت جابهجا میشه؛ اما گوگل باید رابطه نسخه قدیم و جدید را دوباره بفهمه
دامنه و URLهای فعلی سابقه، لینک، ایندکس و رفتار کاربر جمع کردهان. در مهاجرت، باید این سیگنالها با کمترین ابهام به مقصد درست منتقل بشن. یک ریدایرکت کلی به صفحه اصلی یا حذف دستههای قدیمی، جای نقشه انتقال دقیق را نمیگیره.
افت کوتاهمدت ممکنه اتفاق بیفته؛ کاری که میشه انجام داد، کاهش ریسک، کوتاهکردن زمان ابهام و واکنش سریع به خطاست.
مقصد اشتباه URLها
صفحه قدیمی به مقصد نامرتبط یا صفحه اصلی میرسه و ارتباط موضوعی از بین میره.
سیگنالهای متناقض
Redirect، Canonical، Sitemap و لینک داخلی به نسخههای متفاوت اشاره میکنن.
انتشار بدون Staging QA
Noindex، robots، کد پاسخ یا محتوای قالبها بعد از انتشار تازه دیده میشن.
پایش دیرهنگام
خطای روز اول چند هفته ادامه پیدا میکنه و دامنه درگیری بزرگتر میشه.
هر تغییر بزرگ سایت میتونه یک پروژه مهاجرت سئو باشه
دامنه کار براساس چیزی که تغییر میکنه مشخص میشه؛ گاهی فقط آدرس دامنه عوض میشه و گاهی همزمان CMS، معماری، محتوا و URLها تغییر میکنن.
تغییر دامنه یا برند
انتقال کامل سایت از دامنه قدیم به دامنه جدید با حفظ رابطه صفحهبهصفحه.
- Change of Address در شرایط مناسب
- ریدایرکت دامنه و پروتکل
- بهروزرسانی داراییهای برند
تغییر CMS یا تکنولوژی
مهاجرت از وردپرس، فروشگاهساز یا سیستم اختصاصی به ساختار فنی جدید.
- کنترل Render و HTML خروجی
- حفظ Meta، Schema و محتوا
- تست Crawl روی Staging
تغییر ساختار URL
بازطراحی پوشهها، دستهها، نامکها یا معماری صفحات بدون قطع مسیر قدیمی.
- تطبیق یکبهیک مقصدها
- رفع زنجیرههای Redirect
- اصلاح لینکسازی داخلی
ادغام یا تفکیک سایتها
ادغام چند دامنه، انتقال یک بخش از سایت یا جداکردن زیرشاخه به دامنه مستقل.
- تصمیم در سطح Page و Query
- کنترل Cross-domain signals
- پایش بخشهای منتقلشده
مهاجرت از روز انتشار شروع نمیشه
بیشترین ریسک قبل از Launch قابل پیشگیریه. برای همین نقشه انتقال، تست Staging، هماهنگی تیمها و داشبورد پایش باید پیش از انتشار آماده باشن.
قبل از انتشار
Baseline، Map و Staging QA
روز انتشار
کنترل لحظهای مسیرهای حیاتی
بعد از انتشار
Crawl، Index و Performance
خروجیهای آمادهسازی
- ثبت Baseline ترافیک، رتبه و Conversion
- Crawl کامل دامنه فعلی و خروجی URLها
- ساخت Redirect Map با تصمیم هر صفحه
- کنترل Meta، Canonical، Schema و Hreflang
- تست قالبها و دسترسی ربات در Staging
چکلیست Launch
- تست نمونه و انبوه کدهای پاسخ
- بررسی robots.txt و حذف Noindex موقت
- انتشار Sitemapهای نهایی
- کنترل Analytics، GTM و Conversionها
- ثبت تغییرات و زمان دقیق انتشار
پایش و اصلاح
- Crawl روزانه مسیرهای درآمدی
- بررسی Coverage و Page Indexing
- مقایسه Click و Impression با Baseline
- کنترل خطاهای 404، 5xx و Soft 404
- اصلاح سریع الگوهای خطای کشفشده
هر URL قدیمی باید یک تصمیم روشن داشته باشه
Redirect Map فقط دو ستون آدرس قدیم و جدید نیست. وضعیت صفحه، مقصد موضوعی، کد پاسخ، Canonical نهایی و دلیل تصمیم ثبت میشن تا تیم فنی بتونه اجرا کنه و تیم سئو بتونه نتیجه را کنترل کنه.
/category/seo/←/services/seo/مرتبط/blog/old-guide/←/blog/new-guide/همنیت/product/alpha/←/products/alpha/یکبهیک/campaign/expired/←removedحذفشدهتیم فنی، محتوا و مدیریت هرکدوم چیزی را میگیرن که لازم دارن
مهاجرت با یک PDF کلی جلو نمیره. تصمیمها باید به فایل، Ticket، معیار پذیرش و مسئول مشخص تبدیل بشن.
Migration Brief
محدوده تغییرات، ریسکها، وابستگیها، مسئول هر بخش و ترتیب اجرا برای همراستایی همه تیمها.
برای مدیریت پروژهURL & Redirect Map
فهرست URLهای قدیمی، مقصد جدید، کد پاسخ، وضعیت Canonical و تصمیم صفحات حذفشده.
برای تیم فنیStaging QA Report
یافتههای قابلتکرار روی نسخه آزمایشی همراه با URL نمونه، شدت ریسک و معیار پذیرش.
برای توسعه و QALaunch Runbook
چکلیست زمانبندیشده روز انتشار، ترتیب تستها، مسیر Escalation و برنامه برگشت در خطای جدی.
برای روز انتشارMonitoring Dashboard
Baseline و مقایسه روند Crawl، Index، Click، Impression، Landing Page و Conversionهای اصلی.
برای پایشRecovery Backlog
فهرست اقدامهای فوری و بهبودهای بعدی که براساس دادههای واقعی پس از انتشار اولویت میگیرن.
برای تثبیت رشدافت را فقط نگاه نمیکنیم؛ منشأش را در سطح صفحه پیدا میکنیم
نوسان کل سایت بهتنهایی چیزی را توضیح نمیده. پوشهها، قالبها، صفحات ورودی و Queryهای حساس جدا میشن تا مشخص بشه انتقال طبیعی در جریانه یا یک خطای قابلاصلاح وجود داره.
قبل از تغییر دامنه یا ساختار سایت
زمان، دامنه کار و شدت پایش براساس اندازه سایت و همزمانی تغییرات مشخص میشه.
آیا تغییر دامنه حتماً باعث افت رتبه میشه؟
افت موقت ممکنه رخ بده، اما شدت و مدت اون به کیفیت نقشه URL، ریدایرکتها، هماهنگی سیگنالهای فنی و سرعت کشف دامنه جدید بستگی داره. هدف مهاجرت حرفهای، کنترل ریسک و بازیابی سریعتر سیگنالهاست؛ نه وعده غیرواقعی افت صفر.
ریدایرکتهای دامنه قدیم را تا چه زمانی نگه داریم؟
ریدایرکتهای دائمی باید بلندمدت حفظ بشن. حذف زودهنگام میتونه کاربران، بکلینکها و سیگنالهای URLهای قدیمی را قطع کنه. مدت دقیق با توجه به نوع مهاجرت و وضعیت Crawl تصمیمگیری میشه.
ابزار Change of Address سرچ کنسول بهتنهایی کافیه؟
نه. این ابزار فقط برای بعضی تغییر دامنهها کاربرد داره و جای Redirect Map، Canonical، Sitemap، لینک داخلی و QA فنی را نمیگیره.
تیم سئو از چه زمانی باید وارد پروژه بشه؟
قبل از نهاییشدن ساختار URL و توسعه نسخه جدید. وقتی طراحی و توسعه کامل شده باشه، اصلاح معماری و قالبها هزینه بیشتری داره و بعضی تصمیمهای پرریسک سختتر تغییر میکنن.
آیا باید طراحی، CMS و دامنه را همزمان تغییر بدیم؟
اگر امکانش هست، کمکردن تعداد تغییرهای همزمان تشخیص خطا را سادهتر میکنه. اگر تغییرها باید همزمان باشن، Baseline، تست Staging و تفکیک مسئولیتها اهمیت بیشتری پیدا میکنه.
بعد از انتشار چه چیزهایی پایش میشن؟
کد پاسخ URLها، زنجیره و حلقه ریدایرکت، Crawl، Indexing، Canonical، Sitemap، خطاهای سرور، کلیک و Impression، صفحات ورودی و Conversionهای مهم بررسی میشن.
تغییر بزرگ سایت را به یک انتقال قابلکنترل تبدیل کنیم
آدرس فعلی، نوع تغییر و زمان تقریبی انتشار را بفرستید. بررسی میکنیم پروژه به Audit قبل از مهاجرت، راهبری کامل یا فقط QA و پایش بعد از Launch نیاز داره.
دیدگاهها و پاسخها
تجربه، سؤال یا پیشنهادتان را مطرح کنید؛ پاسخها پس از بررسی منتشر میشوند.
اولین دیدگاه این صفحه را ثبت کنید.