سئو مهاجرت سایت؛ چگونه هنگام بازطراحی رتبه‌ها را حفظ کنیم؟

سئو مهاجرت سایت چیست؟

سئو مهاجرت سایت برنامه‌ای برای مدیریت تغییرات وب‌سایت از دید موتور جست‌وجو است. در این برنامه مشخص می‌کنیم هر صفحه قدیمی در نسخه جدید چه وضعیتی دارد، چه URLهایی حفظ یا تغییر می‌کنند، کدام محتوا باید منتقل شود و موتور جست‌وجو چگونه باید مقصد جدید صفحات تغییرکرده را تشخیص دهد.

اصطلاح Migration گاهی فقط برای تغییر دامنه استفاده می‌شود، اما از دید عملی سئو دامنه تغییرات گسترده‌تر است. تغییر CMS، ساختار URL، معماری اطلاعات، دسته‌بندی فروشگاه، HTTPS، هاست یا طراحی رابط کاربری ممکن است هرکدام روی بخشی از فرایند Crawl، Indexing، Canonicalization یا ارزیابی صفحه اثر بگذارند.

نکته مهم این است که همه بازطراحی‌ها Site Move کامل نیستند. اگر طراحی ظاهری تغییر کند اما URL، محتوای اصلی، ساختار لینک‌ها و وضعیت فنی صفحات ثابت بماند، پروژه ساده‌تر است. هرچه تعداد مؤلفه‌هایی که هم‌زمان تغییر می‌کنند بیشتر شود، نیاز به برنامه مهاجرت دقیق‌تر خواهد شد.

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

• حفظ URLهای ارزشمند تا حد ممکن
• انتقال صحیح URLهای تغییرکرده
• جلوگیری از ۴۰۴ گسترده و مسیرهای شکسته
• حفظ موضوع و نیت جست‌وجوی صفحات مهم
• انتقال لینک‌های داخلی به ساختار جدید
• حفظ یا اصلاح Canonicalها
• جلوگیری از انتشار Noindex ناخواسته
• معرفی URLهای نهایی در Sitemap
• پایش Crawl، Index و Performance پس از Launch
• جلوگیری از گم شدن داده‌های Analytics و Conversion Tracking

چه تغییراتی به SEO Migration نیاز دارند؟

شدت برنامه مهاجرت باید با نوع تغییرات مت>

شدت برنامه مهاجرت باید با نوع تغییرات متناسب باشد. تغییر رنگ و Typography صفحه با انتقال کامل فروشگاه به CMS جدید یکسان نیست.

اگر قرار است دامنه، CMS و Layout همگی تغییر کنند، بهتر است تا حد ممکن پروژه به مراحل قابل کنترل تقسیم شود. Google در راهنمای Site Move توصیه می‌کند تغییرات بزرگ مانند تغییر Domain، CMS و Layout را در صورت امکان یکی‌یکی اجرا کنید تا تشخیص اثر هر تغییر و مدیریت خطا ساده‌تر باشد.

چرا بازطراحی سایت می‌تواند روی رتبه‌های گوگل اثر بگذارد؟

گوگل ظاهر گرافیکی جدید را به‌عنوان یک جریمه تلقی نمی‌کند. مسئله تغییر سیگنال‌هایی است که برای شناخت URL و محتوای آن استفاده می‌شوند.

صفحه‌ای که امروز رتبه دارد مجموعه‌ای از ویژگی‌ها را در طول زمان ایجاد کرده است: URL مشخص، موضوع و نیت مشخص، لینک‌های داخلی، شاید بک‌لینک خارجی، Title، هدینگ، محتوا، تصاویر، داده ساختاریافته و رفتار کاربران. اگر نسخه جدید چند مورد از این ویژگی‌ها را هم‌زمان تغییر دهد، موتور جست‌وجو باید صفحه را در وضعیت جدید دوباره پردازش کند.

هفت علت رایج افت بعد از بازطراحی

1. حذف URL بدون Redirect: صفحه‌ای که قبلاً پاسخ ۲۰۰ داشته ناگهان ۴۰۴ می‌شود.
2. Redirect اشتباه: صفحه قدیمی به مقصد نامرتبط یا صفحه اصلی منتقل می‌شود.
3. کاهش شدید محتوا: بخش‌هایی که برای پوشش موضوع صفحه مهم بودند حذف می‌شوند.
4. تغییر لینک‌های داخلی: صفحه مهم دیگر از هاب‌ها و صفحات مرتبط لینک کافی دریافت نمی‌کند.
5. Canonical اشتباه: صفحه جدید URL دیگری را Canonical اعلام می‌کند.
6. Noindex یا robots.txt: محدودیت محیط Staging روی Production باقی می‌ماند.
7. ضعف فنی نسخه جدید: سرعت، رندر موبایل یا JavaScript دسترسی به محتوای اصلی را دشوار می‌کند.

از سوی دیگر، نوسان کوتاه‌مدت همیشه نشانه شکست نیست. Google توضیح می‌دهد که در Site Moveهای قابل توجه ممکن است در دوره Recrawl و Reindex نوسان رتبه دیده شود و زمان پردازش برای سایت‌های کوچک و متوسط می‌تواند چند هفته طول بکشد.

مرحله اول: قبل از مهاجرت یک خط مبنای سئو بسازید

اولین مرحله یک پروژه حرفه‌ای، Backup گرفتن از فایل سایت نیست؛ بلکه ثبت وضعیت فعلی سئو است. Backup فنی برای بازگرداندن اطلاعات لازم است، اما Baseline سئو مشخص می‌کند چه چیزی نباید در جریان پروژه گم شود.

داده‌های Google Search Console

قبل از شروع تغییرات، Performance Report را برای بازه‌ای مناسب Export کنید. حداقل Query، Page، Click، Impression، CTR و Average Position صفحات مهم ثبت شوند.

هدف این Export ساختن فهرست «صفحات دارای ارزش جست‌وجویی» است. صفحه‌ای که طراحی تیم آن را کم‌اهمیت می‌داند ممکن است در عمل یکی از Landing Pageهای اصلی ورودی ارگانیک باشد.

داده‌های Analytics

Landing Pageهای ارگانیک، Conversionها، تماس‌ها، ارسال فرم، خرید و سایر رویدادهای مهم را ثبت کنید. مهاجرت موفق فقط به این معنا نیست که URL در Google باقی مانده باشد؛ مسیر تبدیل کاربران نیز باید سالم بماند.

Backlink و لینک‌های خارجی

URLهایی که از دامنه‌های دیگر لینک دریافت کرده‌اند اهمیت ویژه دارند. اگر چنین URLهایی تغییر کنند باید Redirect مقصد آن‌ها با دقت تعیین شود. پس از مهاجرت نیز در صورت امکان می‌توان از سایت‌های مهم درخواست کرد لینک خارجی را مستقیماً به URL جدید به‌روزرسانی کنند.

Baseline فنی

• Status Code صفحات
• Canonical
• Robots Meta
• Title و Description
• H1
• Structured Data
• Internal Link Count
• Page Depth
• Core Web Vitals و PageSpeed صفحات مهم
• Sitemap فعلی

این اطلاعات بعدها به تیم اجازه می‌دهند نسخه قبل و بعد را به‌صورت واقعی مقایسه کند.

مرحله دوم: Inventory کامل URLهای سایت را تهیه کنید

برای سایت کوچک، فهرست URL ممکن است چند ده صفحه باشد؛ برای فروشگاه یا سایت محتوایی می‌تواند هزاران URL داشته باشد. مهم این است که فهرست فقط به Sitemap محدود نشود.

طبق راهنمای Google برای Site Move، برای پیدا کردن URLهای مهم می‌توان از Sitemap، Analytics، Server Log و گزارش لینک‌های Search Console استفاده کرد. همچنین URL تصاویر، ویدئوها و فایل‌های مهمی که احتمال دارد ورودی یا لینک خارجی داشته باشند باید در برنامه انتقال در نظر گرفته شوند.

URLها را از چه منابعی جمع کنیم؟

• XML Sitemap
• Crawl کامل سایت
• Google Search Console
• Google Analytics
• CMS
• Server Log
• Backlink Tools
• URLهای کمپین و Landing Pageهای قدیمی
• محصولات و دسته‌بندی‌های فروشگاه
• فایل‌ها و PDFهای دارای ورودی

پس از جمع‌آوری، URLهای Duplicate و پارامتری را از URLهای اصلی جدا کنید تا نقشه اصلی روی صفحات Canonical متمرکز باشد.

مرحله سوم: URL Mapping؛ هر صفحه قدیمی باید یک تصمیم مشخص داشته باشد

URL Mapping قلب مهاجرت است. برای هر URL قدیمی مشخص کنید در ساختار جدید چه اتفاقی رخ می‌دهد.

آیا باید همه URLها را در بازطراحی عوض کنیم؟

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

URL جدید باید چه ویژگی‌هایی داشته باشد؟

• موضوع صفحه را روشن منتقل کند.
• کوتاه و پایدار باشد.
• به فناوری موقت یا سالی که قرار است زود منقضی شود وابسته نباشد، مگر موضوع صفحه واقعاً زمانی باشد.
• با معماری دسته‌بندی سایت هماهنگ باشد.
• در آینده نیازمند تغییر مکرر نباشد.

مرحله چهارم: Redirect ۳۰۱ را به‌عنوان بخشی از معماری مهاجرت اجرا کنید

Google در مستندات Redirects and Google Search، Redirect دائمی مانند HTTP ۳۰۱ و ۳۰۸ را برای انتقال دائمی URLها توصیه می‌کند. در Site Move نیز توصیه اصلی استفاده از Redirectهای دائمی Server-side در صورت امکان است.

نکته مهم دیگر این است که طبق مستندات فعلی Google، Redirectهای دائمی ۳۰۱ باعث از دست رفتن PageRank به شیوه‌ای که در گذشته گاهی تصور می‌شد نمی‌شوند. با این حال، این به معنی بی‌اهمیت بودن کیفیت Redirect نیست؛ مقصد نامرتبط یا زنجیره طولانی همچنان می‌تواند تجربه و پردازش سایت را خراب کند.

قواعد Redirect Mapping

• هر URL قدیمی مستقیماً به مقصد نهایی Redirect شود.
• از زنجیره Old → Intermediate → New خودداری کنید.
• Redirect به صفحه‌ای که خود آن Redirect است اصلاح شود.
• صفحه خدمات قدیمی به صفحه خدمات مرتبط جدید منتقل شود، نه صفحه اصلی.
• محصول قدیمی فقط زمانی به Category منتقل شود که واقعاً جایگزین بهتری وجود نداشته باشد.
• قوانین Wildcard قبل از انتشار روی نمونه URLها تست شوند.

Redirectها را چه مدت نگه داریم؟

Google برای Site Moveهای دارای تغییر URL توصیه می‌کند Redirectها تا حد امکان طولانی نگه داشته شوند و حداقل حدود یک سال باقی بمانند تا سیستم‌های Google فرصت انتقال و پردازش سیگنال‌های URLهای قدیمی را داشته باشند. از نگاه کاربر، در بسیاری از پروژه‌ها نگهداری طولانی‌تر Redirect نیز منطقی است.

چرا Redirect همه URLها به Home اشتباه است؟

Google صراحتاً هشدار می‌دهد که Redirect تعداد زیادی URL قدیمی به یک مقصد نامرتبط مانند Home می‌تواند گیج‌کننده باشد و حتی به‌عنوان Soft ۴۰۴ تفسیر شود. مقصد باید نزدیک‌ترین معادل واقعی صفحه قدیمی باشد.

مرحله پنجم: محتوا را منتقل کنید، نه فقط طرح گرافیکی را

در بازطراحی، تیم طراحی معمولاً تمایل دارد صفحه‌ها تمیزتر، کوتاه‌تر و مینیمال‌تر شوند. این هدف لزوماً بد نیست؛ اما باید بدانیم چه بخشی از محتوای فعلی برای پاسخ‌گویی به کاربر و رتبه صفحه اهمیت دارد.

اگر یک صفحه درباره چند زیرموضوع مرتبط Impression و رتبه گرفته است، حذف آن زیرموضوع‌ها ممکن است دامنه معنایی صفحه را کاهش دهد. بنابراین Content Migration باید بر اساس داده انجام شود، نه فقط اندازه بلوک‌های طراحی.

برای هر صفحه مهم این موارد مقایسه شوند

• Search Intent فعلی
• Primary Topic
• Queryهای ورودی
• Title
• Meta Description
• H1
• H2 و H3های ضروری
• پاراگراف‌های اصلی
• جدول‌ها و داده‌های مفید
• FAQهای واقعی
• Internal Links
• تصاویر دارای ارزش
• Structured Data مرتبط

آیا Title و Description باید عیناً حفظ شوند؟

نه لزوماً. مهاجرت می‌تواند فرصت خوبی برای اصلاح Title و Description ضعیف باشد. اما تغییر همه چیز در یک لحظه تحلیل نتیجه را دشوار می‌کند. برای صفحات دارای عملکرد خوب بهتر است تغییرات غیرضروری را محدود کنید یا حداقل نسخه قبلی را مستند نگه دارید.

هدینگ‌های صفحه چه نقشی دارند؟

صفحه جدید باید یک ساختار معنایی روشن داشته باشد. H1 اصلی باید با موضوع صفحه هماهنگ باشد و H2/H3ها زیرموضوع‌ها را سازمان‌دهی کنند. ساختن چند نسخه متفاوت از محتوای Desktop و Mobile و قرار دادن هر دو داخل DOM معمولاً راه مناسبی نیست؛ یک ساختار محتوایی مشترک و Responsive تمیزتر است.

مرحله ششم: معماری لینک داخلی نسخه جدید را از صفر بررسی کنید

وقتی Navigation تغییر می‌کند، Depth صفحات نیز ممکن است تغییر کند. صفحه‌ای که قبلاً از منوی اصلی، Home و چند Category لینک داشت ممکن است پس از بازطراحی فقط از یک مقاله قدیمی قابل دسترس باشد.

برای صفحات تجاری و محتوایی مهم باید بررسی شود:

• آیا از هاب موضوعی مرتبط لینک دارند؟
• آیا از صفحات نزدیک به همان Intent لینک دریافت می‌کنند؟
• آیا Anchor Text مقصد را توضیح می‌دهد؟
• آیا URLهای قدیمی هنوز داخل محتوای سایت وجود دارند؟
• آیا Navigation موبایل همان دسترسی محتوایی لازم را فراهم می‌کند؟
• آیا Breadcrumbها مسیر واقعی سایت را نشان می‌دهند؟

پس از Launch بهتر است Crawl کامل جدید اجرا و تمام Internal Redirectها شناسایی شوند. حتی اگر Redirect کار کند، لینک داخلی سایت بهتر است مستقیماً به URL نهایی اشاره کند.

مرحله هفتم: Canonical، Robots و Indexability را قبل از Launch کنترل کنید

Canonical

در نسخه جدید هر صفحه اصلی باید Canonical مناسب خود را اعلام کند. Google در راهنمای Canonicalization توضیح می‌دهد که Redirect، rel=”canonical” و Sitemap از سیگنال‌های انتخاب URL Canonical هستند و بهتر است این سیگنال‌ها با یکدیگر هماهنگ باشند.

در پروژه مهاجرت نباید Sitemap URL جدید را معرفی کند اما Canonical صفحه به URL قدیمی یا Host دیگری اشاره داشته باشد.

Robots Meta

محیط Staging معمولاً Noindex است. قبل از انتشار نسخه Production تمام Templateها، Post Typeها، Taxonomyها و صفحات کلیدی بررسی شوند تا Noindex ناخواسته باقی نماند.

robots.txt

اگر محیط آزمایشی از `Disallow: /` استفاده کرده است، فایل Production باید قبل از انتشار آماده شود. robots.txt ابزار کنترل Crawl است و جایگزین مدیریت صحیح Indexing نیست.

Structured Data

در تغییر Theme یا CMS ممکن است Schema قبلی حذف، تکراری یا ناقص شود. Organization، Breadcrumb، Article، Product و سایر Schemaهای واقعی سایت باید بعد از انتقال دوباره Validate شوند و با محتوای قابل مشاهده صفحه مطابقت داشته باشند.

مرحله هشتم: Sitemap و Search Console را وارد برنامه انتشار کنید

Sitemap جدید باید فقط URLهایی را معرفی کند که نسخه Canonical و نهایی سایت هستند. URLهایی که ۳۰۱ می‌شوند نباید به‌عنوان URL فعال مقصد جدید در Sitemap اصلی باقی بمانند.

قبل از انتشار

• مالکیت Search Console بررسی شود.
• Sitemap قدیمی Export و ذخیره شود.
• URLهای مهم Index شده ثبت شوند.
• Performance صفحات مهم Export شود.

بعد از انتشار

• Sitemap جدید Submit شود.
• چند URL مهم با URL Inspection بررسی شوند.
• Canonical انتخاب‌شده توسط Google بررسی شود.
• Page Indexing برای افزایش ۴۰۴ یا خطاهای Server پایش شود.
• Performance بر اساس Page و Query مقایسه شود.

اگر تغییر فقط Pathهای داخل همان Domain است، Change of Address لازم نیست. این ابزار برای مهاجرت Domain یا Subdomain استفاده می‌شود. برای HTTP به HTTPS نیز Google می‌گوید نیازی به Change of Address نیست.

سئو مهاجرت سایت وردپرسی؛ چه چیزهایی فراتر از انتقال نوشته‌هاست؟

وردپرس از نظر مهاجرت ساده به نظر می‌رسد، اما URLهای سایت فقط Posts و Pages نیستند. Taxonomyها، Attachmentها، Author Archive، Category، Tag، Custom Post Type، Custom Taxonomy، Pagination و در سایت‌های فروشگاهی Product و Product Category نیز بخشی از ساختار هستند.

در پروژه‌های طراحی سایت وردپرس تابان استودیو، ساختار صفحات، مدیریت محتوا، لینک‌سازی، سرعت و امکان توسعه آینده باید قبل از تغییرات گسترده بررسی شوند. اگر یک سایت وردپرسی فعال بازطراحی می‌شود، بهتر است ساختار فعلی URL و Taxonomy قبل از اعمال Permalink جدید مستند شود.

چک‌لیست مهاجرت وردپرس

• Settings → Permalinks
• Post و Page Slugها
• Category Slugها
• Custom Post Type Rewrite Rules
• Media URLها
• Canonical تولیدشده توسط افزونه SEO
• XML Sitemap
• Robots Meta
• Breadcrumb
• Schema
• Redirect Plugin یا Server Rules
• Internal Links داخل Gutenberg یا Elementor
• فرم‌ها و Shortcodeها
• Search و Archive Templateها

مهاجرت Elementor و قالب

اگر بازطراحی با Elementor انجام می‌شود، فقط ظاهر صفحات را بررسی نکنید. بعضی Templateهای Theme Builder ممکن است H1، Breadcrumb، Archive Title یا محتوای یکسان را چند بار تولید کنند. نسخه موبایل نیز نباید محتوای اصلی متفاوت یا ناقص داشته باشد.

برای سایت‌هایی که پس از مهاجرت به نگهداری مداوم نیاز دارند، صفحه خدمات پشتیبانی سایت وردپرس تابان استودیو مسیر نگهداری، به‌روزرسانی، امنیت، رفع خطا، سرعت و پشتیبانی ماهانه را پوشش می‌دهد.

سئو مهاجرت فروشگاه ووکامرس؛ ریسک اصلی در تعداد URLهاست

فروشگاه ووکامرس معمولاً از یک سایت شرکتی URLهای بسیار بیشتری دارد. Product، Category، Tag، Attribute، Pagination، Filter، Search Result، Brand و صفحات کمپین می‌توانند هرکدام URL تولید کنند.

در بازطراحی فروشگاه ابتدا باید مشخص شود کدام URLها واقعاً Indexable و ارزشمند هستند. تغییر ساختار Product Category بدون Mapping می‌تواند صدها صفحه را هم‌زمان جابه‌جا کند.

محصولات

URL محصول پرفروش یا محصولی که از گوگل ورودی دارد نباید بدون دلیل تغییر کند. اگر محصول حذف شده، باید مشخص شود جایگزین مستقیم دارد، Category مرتبط وجود دارد یا بهتر است پاسخ واقعی ۴۰۴/۴۱۰ برگرداند.

دسته‌بندی محصولات

Category Pageها اغلب برای کلمات عمومی‌تر فروشگاهی هدف مناسبی هستند. ادغام یا تغییر Slug دسته‌ها باید همراه با Redirect و بازسازی Internal Link محصولات انجام شود.

فیلتر و Attribute

قبل و بعد از مهاجرت بررسی کنید کدام ترکیب‌های Filter قابل Index هستند و کدام باید Crawl یا Index کنترل‌شده داشته باشند. انتقال بی‌برنامه می‌تواند تعداد زیادی URL جدید و کم‌ارزش ایجاد کند.

Structured Data محصول

قیمت، موجودی، Breadcrumb و اطلاعات Product پس از تغییر Theme یا WooCommerce Template باید Validate شوند.

در پروژه‌هایی که بازطراحی با ساخت فروشگاه جدید ترکیب می‌شود، خدمات طراحی سایت فروشگاهی تابان استودیو روی انتخاب زیرساخت، تجربه خرید، مدیریت محصول و سفارش، پرداخت، مالکیت فنی و توسعه‌پذیری فروشگاه تمرکز دارد.

سرعت سایت بعد از بازطراحی؛ نسخه زیباتر نباید سنگین‌تر شود

بازطراحی معمولاً تصاویر جدید، فونت، JavaScript، Animation و Componentهای بیشتری وارد سایت می‌کند. اگر Budget عملکردی تعریف نشده باشد، ممکن است نسخه جدید ظاهراً بهتر اما از نظر تجربه واقعی کندتر شود.

Google در مستندات Core Web Vitals سه معیار اصلی تجربه را LCP، INP و CLS معرفی می‌کند و برای تجربه خوب حدود LCP زیر ۲.۵ ثانیه، INP کمتر از ۲۰۰ میلی‌ثانیه و CLS کمتر از ۰.۱ را پیشنهاد می‌کند.

قبل و بعد را روی URLهای یکسان مقایسه کنید

PageSpeed فقط برای Home گرفته نشود. صفحات خدمات، مقاله، Product و Category نمونه انتخاب و قبل و بعد از پروژه مقایسه شوند.

مواردی که در بازطراحی معمولاً Performance را خراب می‌کنند

• Hero Image بسیار بزرگ
• Lazy Load اشتباه روی LCP Image
• فونت‌های متعدد
• JavaScript غیرضروری
• Sliderهای سنگین
• DOM بسیار بزرگ
• انیمیشن‌های متعدد
• Third-party Scriptها
• CSS و JS بلااستفاده
• تصاویر بدون ابعاد مشخص و ایجاد CLS

Analytics و Conversion Tracking را در مهاجرت فراموش نکنید

گاهی سایت از نظر سئو درست منتقل می‌شود اما داده‌های تجاری قطع می‌شوند. پس از تغییر Theme یا CMS ممکن است Google Analytics، Tag Manager، Conversionهای تبلیغاتی، Pixelها، Eventها یا فرم Tracking از Template حذف شوند.

قبل از انتشار فهرست تمام ابزارهای اندازه‌گیری تهیه کنید و پس از Launch Eventهای مهم را تست کنید:

• ارسال فرم
• تماس تلفنی
• واتس‌اپ
• ثبت‌نام
• Add to Cart
• Checkout
• Purchase
• ورود به پنل سفارش
• دانلود فایل

مهاجرتی که رتبه را حفظ کند اما امکان اندازه‌گیری Lead و Sale را از بین ببرد همچنان یک پروژه ناقص است.

چک‌لیست روز Launch؛ قبل از باز کردن سایت برای کاربران چه چیزهایی بررسی شوند؟

بعد از انتشار سایت جدید چه زمانی چه چیزی را بررسی کنیم؟

افت یک صفحه را چگونه عیب‌یابی کنیم؟

به‌جای بازنویسی فوری صفحه، این ترتیب منطقی‌تر است:

1. آیا URL تغییر کرده است؟
2. آیا Redirect صحیح است؟
3. آیا Google URL جدید را Index کرده است؟
4. Canonical اعلام‌شده چیست؟
5. محتوای اصلی نسبت به قبل تغییر کرده است؟
6. Internal Linkها کم شده‌اند؟
7. Title و H1 تغییر کرده‌اند؟
8. صفحه در موبایل قابل استفاده است؟
9. خطای Server یا JavaScript وجود دارد؟
10. آیا افت مربوط به کل سایت است یا فقط یک Query؟

تفاوت مهاجرت با تغییر دامنه و مهاجرت داخل همان دامنه

بازطراحی روی همان Domain

اگر فقط URL Pathها یا CMS تغییر می‌کنند، نیازی به Change of Address نیست. تمرکز روی Mapping، Redirect، Canonical، Sitemap و Internal Links خواهد بود.

تغییر Domain

اگر کل سایت از یک Domain یا Subdomain به دیگری منتقل می‌شود، علاوه بر Redirect و Sitemap باید Propertyهای مربوطه در Search Console تأیید و Change of Address طبق شرایط Google استفاده شود.

HTTP به HTTPS

این نوع انتقال نیز نیازمند Redirect صحیح به HTTPS و به‌روزرسانی URLهای داخلی است، اما Google برای HTTP به HTTPS استفاده از Change of Address را لازم نمی‌داند.

بازطراحی و مهاجرت CMS را هم‌زمان انجام دهیم یا جدا؟

این یکی از مهم‌ترین تصمیم‌های پروژه است. گاهی کسب‌وکار مجبور است CMS قدیمی را هم‌زمان با طراحی کنار بگذارد؛ زیرا معماری جدید روی سیستم قبلی قابل اجرا نیست. در این شرایط باید پروژه را به‌عنوان یک Migration واقعی مدیریت کرد.

اگر محدودیت فنی وجود ندارد، کاهش تعداد تغییرات هم‌زمان معمولاً عیب‌یابی را ساده‌تر می‌کند. برای مثال ابتدا می‌توان دامنه را ثابت نگه داشت و CMS و Layout را مهاجرت داد، یا برعکس تغییر Domain را از تغییر اساسی معماری جدا کرد.

زمانی که مهاجرت CMS منطقی است

• CMS فعلی دیگر پشتیبانی نمی‌شود.
• ویرایش محتوا بسیار دشوار است.
• زیرساخت امنیتی و فنی قابل نگهداری نیست.
• افزودن قابلیت‌های لازم هزینه غیرمنطقی دارد.
• ساختار داده با نیازهای جدید کسب‌وکار هماهنگ نیست.
• تیم داخلی امکان مدیریت سیستم را ندارد.

در چنین پروژه‌ای باید Content Model، URL، Media، User Role، Integration، فرم، CRM، API و SEO همگی در Scope مهاجرت باشند.

۱۵ اشتباه پرریسک در سئو مهاجرت سایت

1. شروع طراحی بدون Crawl نسخه فعلی
2. تغییر همه URLها برای زیباتر شدن Slug
3. حذف صفحات کم‌ظاهر اما پربازدید
4. Redirect همه URLهای قدیمی به Home
5. ساخت Redirect Chain
6. انتقال ناقص Metadata
7. Canonical به Staging Domain
8. باقی ماندن Noindex
9. باقی ماندن Disallow عمومی
10. حذف Internal Linkهای مهم
11. عدم انتقال Schema
12. حذف صفحات Category فروشگاه بدون Mapping
13. عدم تست موبایل
14. قطع Analytics و Conversion
15. عدم پایش چهار هفته اول پروژه

آیا بعد از بازطراحی باید تمام صفحات را Request Indexing کنیم؟

خیر. Request Indexing راه‌حل یک مهاجرت گسترده نیست. Sitemap، Internal Link، Redirect صحیح و Crawlable بودن سایت زیرساخت اصلی Discovery و Reprocessing هستند.

URL Inspection برای صفحات استراتژیک و عیب‌یابی بسیار مفید است، اما برای صدها یا هزاران URL نباید جای معماری فنی درست را بگیرد.

چطور بفهمیم مهاجرت موفق بوده است؟

موفقیت را فقط با این سؤال نسنجید که «آیا رتبه کلمه اصلی ثابت ماند؟». یک پروژه موفق چند KPI دارد:

• URLهای مهم جدید Index شده‌اند.
• URLهای قدیمی به مقصد صحیح Redirect می‌شوند.
• ۴۰۴ غیرمنتظره افزایش نیافته است.
• Click و Impression صفحات تجاری در محدوده قابل انتظار قرار دارند.
• Queryهای ارزشمند روی URLهای درست نمایش داده می‌شوند.
• ترافیک ارگانیک صفحات کلیدی بازیابی یا رشد کرده است.
• Conversionها سالم هستند.
• سرعت و UX نسبت به قبل ضعیف‌تر نشده‌اند.
• Internal Redirect و Broken Link گسترده وجود ندارد.

سئو مهاجرت و بازطراحی سایت در تابان استودیو چگونه به هم متصل می‌شوند؟

تابان استودیو، واحد تخصصی طراحی و توسعه وب شرکت تابان گستران ونداد، بازطراحی را صرفاً تغییر رنگ و ظاهر صفحات نمی‌بیند. در پروژه‌ای که سایت موجود دارای محتوا، ورودی، URLهای ایندکس‌شده یا مشتری فعال است، ابتدا باید وضعیت فعلی بررسی شود و سپس معماری نسخه جدید بر اساس همان داده‌ها شکل بگیرد.

خدمات بازطراحی سایت

در خدمات بازطراحی سایت تابان استودیو، هدف اصلاح ظاهر، معماری صفحات، نسخه موبایل، تجربه کاربری، سرعت و مسیر تبدیل سایت‌های قدیمی یا کم‌بازده است. اگر ساختار URL یا CMS نیز تغییر کند، SEO Migration باید بخشی از برنامه انتشار باشد.

خدمات سئو و سئو تکنیکال

صفحه خدمات سئو تابان استودیو ممیزی فنی، ساختار صفحات، Crawl و Index، سرعت، لینک‌سازی داخلی و معماری محتوا را پوشش می‌دهد. این بخش در مهاجرت برای ساخت Baseline، تشخیص صفحات مهم و پایش پس از Launch کاربرد مستقیم دارد.

طراحی و بازطراحی وردپرس

برای پروژه‌هایی که مقصد آن‌ها WordPress است، طراحی سایت وردپرس بر ساختار مدیریت‌پذیر، سئوپذیر و قابل توسعه تمرکز دارد. انتقال سایت قدیمی به وردپرس باید شامل URLها، محتوا، Taxonomy، Media، فرم‌ها، Sitemap و تنظیمات SEO نیز باشد.

طراحی و مهاجرت فروشگاه اینترنتی

اگر پروژه مربوط به فروش آنلاین است، خدمات طراحی سایت فروشگاهی برای ساخت مسیر خرید، مدیریت محصول، سفارش، پرداخت و توسعه فروشگاه ارائه می‌شود. در فروشگاه موجود، مهاجرت باید Product و Categoryهای دارای ورودی را نیز محافظت کند.

پشتیبانی پس از انتشار

مهاجرت در روز Launch تمام نمی‌شود. خدمات پشتیبانی سایت وردپرس تابان استودیو شامل نگهداری، به‌روزرسانی، رفع خطا، امنیت، سرعت و پایش فنی است و می‌تواند برای دوره تثبیت پس از بازطراحی نیز استفاده شود.

مشاوره قبل از شروع پروژه

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

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

سئو مهاجرت سایت با سئو تکنیکال چه تفاوتی دارد؟

سئو تکنیکال یک حوزه دائمی برای سلامت فنی سایت است؛ اما SEO Migration مجموعه‌ای از کنترل‌های مشخص در دوره تغییر یا انتقال سایت است. Redirect Mapping، حفظ URL، انتقال محتوا و Validation پس از Launch از موضوعات شاخص Migration هستند.

آیا بازطراحی سایت حتماً باعث افت رتبه می‌شود؟

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

در بازطراحی بهتر است URLهای قدیمی را نگه داریم؟

اگر URL صحیح و مرتبط است و دلیلی برای تغییر آن وجود ندارد، حفظ URL می‌تواند پیچیدگی مهاجرت را کاهش دهد. اگر تغییر لازم است، URL Mapping و Redirect دائمی باید از قبل آماده باشند.

آیا ۳۰۱ باعث از دست رفتن رتبه می‌شود؟

Google اعلام کرده Redirectهای دائمی مانند ۳۰۱ به‌خودی‌خود باعث از دست رفتن PageRank نمی‌شوند. اما Redirect باید به مقصد مرتبط، قابل دسترس و نهایی اشاره کند.

Redirectها را چه مدت نگه داریم؟

در Site Moveهای دارای تغییر URL، Google توصیه می‌کند Redirectها حداقل حدود یک سال باقی بمانند و در صورت امکان برای کاربران حتی طولانی‌تر حفظ شوند.

آیا بعد از تغییر دامنه باید Change of Address بزنیم؟

برای انتقال Domain یا Subdomain می‌توان طبق شرایط Google از Change of Address در Search Console استفاده کرد. برای تغییر Path داخل همان Domain یا مهاجرت HTTP به HTTPS این ابزار کاربرد یکسانی ندارد.

آیا تغییر CMS بدون تغییر URL هم ریسک دارد؟

بله. حتی اگر URL ثابت باشد، CMS جدید ممکن است Canonical، Meta، Structured Data، Internal Link، Sitemap یا HTML صفحه را تغییر دهد. بنابراین Migration QA همچنان لازم است.

آیا بعد از بازطراحی همه صفحات را دوباره ایندکس کنیم؟

نیازی به درخواست دستی Index برای تک‌تک URLها نیست. Sitemap، Internal Link، Redirect و Crawlability صحیح مهم‌تر هستند. URL Inspection بیشتر برای صفحات استراتژیک و عیب‌یابی استفاده شود.

آیا فروشگاه ووکامرس Migration متفاوتی دارد؟

اصول اصلی یکسان است اما تعداد URLهای Product، Category، Filter، Pagination و Attribute بیشتر است. به همین دلیل Inventory و Mapping فروشگاه باید دقیق‌تر انجام شود.

چه زمانی باید متخصص سئو وارد پروژه بازطراحی شود؟

پیش از تصمیم قطعی درباره معماری صفحه و URL. ورود تیم سئو بعد از کامل شدن طراحی ممکن است باعث شود برای اصلاح ساختار نیاز به بازکاری قابل توجه وجود داشته باشد.

جمع‌بندی: بازطراحی موفق، گذشته سئوی سایت را دور نمی‌ریزد

سئو مهاجرت سایت زمانی اهمیت پیدا می‌کند که وب‌سایت موجود چیزی برای حفظ کردن داشته باشد: URLهای ایندکس‌شده، صفحات دارای رتبه، بک‌لینک، محتوا، مشتری، Conversion و سابقه‌ای که در طول زمان ساخته شده است.

فرایند صحیح از قبل از طراحی شروع می‌شود: ابتدا Baseline و Inventory ساخته می‌شود، سپس URL Mapping و معماری نسخه جدید مشخص می‌شوند. در مرحله توسعه، محتوا، Metadata، Canonical، Structured Data، لینک‌های داخلی و Tracking منتقل می‌شوند. پیش از Launch، Redirect، Robots، Sitemap، Mobile و Performance کنترل می‌شوند و پس از انتشار نیز Search Console، Analytics و Server Log تحت نظر قرار می‌گیرند.

هدف واقع‌بینانه SEO Migration وعده «صفر نوسان» نیست؛ هدف این است که تغییرات قابل پیش‌بینی، قابل تست و قابل عیب‌یابی باشند و ارزش صفحات موجود بدون دلیل فنی از بین نرود.

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