دقیقه
29 مهر 1405ممکن است نسخه تازه سایت وردپرسی زیباتر، سریع‌تر و برای مشتری راحت‌تر باشد، اما پس از انتشار، بعضی صفحات پربازدید دیگر در دسترس نباشند یا بخش مهمی از محتوای آن‌ها حذف شده باشد. بازطراحی فقط عوض‌کردن رنگ و چیدمان نیست؛ اگر آدرس‌ها، ساختار محتوا یا مسیر دسترسی به صفحات تغییر کنند، باید اثر این تغییرها بر جست‌وجو هم بررسی شود.
هدف این راهنما کاهش ریسک افت سئو در بازطراحی سایت وردپرسی است، نه وعده ثابت‌ماندن همه رتبه‌ها. حتی یک انتقال اصولی ممکن است با نوسان همراه باشد. کاری که می‌توان انجام داد، شناخت دارایی‌های فعلی، محدودکردن تغییرهای بی‌دلیل و داشتن برنامه کنترل و پیگیری است تا ایراد قابل پیشگیری، پشت عبارت «افت طبیعی بعد از طراحی» پنهان نماند.
این بررسی باید پیش از طراحی و کدنویسی شروع شود. اگر تیم سئو زمانی وارد پروژه شود که نسخه تازه آماده انتشار است، ممکن است حفظ صفحات، برگرداندن محتوا یا اصلاح ساختار به کار دوباره نیاز داشته باشد. بهتر است مسئولیت طراحی، توسعه و سئو از ابتدا در یک فهرست مشترک روشن باشد.
ابتدا مشخص کنید در بازطراحی چه چیزهایی تغییر می‌کنند
تعویض قالب با حفظ محتوا و آدرس‌ها، با انتقال به دامنه جدید یا تغییر ساختار همه صفحات یک پروژه یکسان نیست. کنار هدف ظاهری و تجاری، دامنه تغییر فنی را هم بنویسید. هرچه تغییرهای هم‌زمان بیشتر باشند، یافتن علت یک مشکل پس از انتشار دشوارتر می‌شود.
تغییر ظاهر را از تغییر آدرس و معماری جدا کنید
ممکن است همان صفحه خدمت با همان نشانی باقی بماند، اما ترتیب بخش‌ها و نمایش موبایل آن بهتر شود. در این حالت، فقط به دلیل تغییر ظاهر، ریدایرکت لازم نیست. در مقابل، تغییر نامک، ساختار پیوند یکتا یا مسیر دسته‌ها می‌تواند نشانی‌های قبلی را عوض کند و به نقشه انتقال نیاز داشته باشد.
اگر تغییر دامنه، میزبانی، سیستم مدیریت محتوا و طراحی همگی مطرح‌اند، ضرورت و ترتیب آن‌ها را بررسی کنید. در صورت امکان، تغییرهای مستقل را مرحله‌بندی کنید تا دامنه عیب‌یابی محدودتر باشد. این به معنی مرحله‌ای‌کردن اجباری همه پروژه‌ها نیست؛ تصمیم باید با امکان اجرا، وابستگی‌ها و خطر ناهماهنگی نسخه‌ها سازگار باشد.
معیار پذیرش را پیش از شروع بنویسید
عبارت «حفظ سئو» را به خروجی قابل بررسی تبدیل کنید: فهرست صفحات مهم، وضعیت آدرس‌ها، انتقال داده‌های سئو، کنترل نسخه آزمایشی و برنامه پایش پس از انتشار. معلوم باشد چه کسی هر بخش را اجرا می‌کند و چه کسی نتیجه را تأیید می‌کند. ظاهر مورد پسند کارفرما، جای این کنترل‌ها را نمی‌گیرد.
برای اصلاح محدود یا بازطراحی کامل باید مسئله کسب‌وکار را بشناسید؛ اما پس از انتخاب بازطراحی، حفظ دارایی‌های موجود یک کار مستقل است. از مجری بخواهید تغییرهای خارج از دامنه توافق را پیش از اجرا مطرح کند. حذف دسته‌ها یا بازنویسی همه متن‌ها نباید صرفاً برای هماهنگ‌شدن با قالب تازه، بدون بررسی تصویب شود.
پیش از تغییر، از صفحات و داده‌های فعلی نقشه تهیه کنید
بدون فهرست وضعیت موجود، پس از انتشار نمی‌دانید چه چیزی واقعاً از دست رفته است. یک نسخه مرجع از آدرس‌ها، عملکرد و محتوای مهم نگه دارید. این فهرست باید هم به طراحی کمک کند و هم مبنای کنترل نسخه تازه باشد؛ خروجی صرفاً تصویری از صفحه خانه کافی نیست.
فقط صفحات پربازدید را مهم ندانید
داده سرچ کنسول، فهرست صفحات سایت، نقشه سایت و اطلاعات تماس یا فروش را کنار هم بگذارید. صفحه‌ای با ورودی کم ممکن است درخواست تخصصی و ارزشمند ایجاد کند. صفحات دارای لینک بیرونی، فایل‌های دانلودی و تصاویر ورودی‌گیر نیز ممکن است در فهرست ساده منوی اصلی دیده نشوند.
برای هر صفحه مهم، نشانی، هدف، محتوای اصلی و تصمیم آینده را ثبت کنید: حفظ، به‌روزرسانی، ادغام یا حذف. مبنای تصمیم فقط قدیمی‌بودن ظاهر یا کم‌بودن کلیک یک بازه کوتاه نباشد. اگر صفحه نیاز واقعی کاربر را پاسخ می‌دهد، ابتدا امکان اصلاح آن را بررسی کنید و سپس درباره حذف تصمیم بگیرید.
داده‌های سئو و مسیرهای داخلی را ثبت کنید
عنوان سئو، توضیحات متا، تیترها، آدرس اصلی صفحه یا canonical، وضعیت ایندکس و لینک‌های داخلی مهم را برای صفحات منتخب نگه دارید. در وردپرس، این داده‌ها ممکن است بخشی در محتوا و بخشی در تنظیمات افزونه یا فیلدهای اختصاصی باشند. انتقال نوشته‌ها به‌تنهایی ثابت نمی‌کند همه این اطلاعات منتقل شده‌اند.
هم‌زمان مشخص کنید کاربر چگونه از مقاله به خدمت، از دسته به محصول و از صفحه مقصد به فرم می‌رسد. بازطراحی ممکن است صفحه را نگه دارد، ولی لینک‌های ورودی داخلی آن را از بین ببرد. ثبت مسیرها کمک می‌کند معماری تازه، دسترسی به صفحات مهم را حفظ کند و صرفاً بر اساس چیدمان منوی جدید ارزیابی نشود.
برای آدرس‌های حفظ‌شده، تغییرکرده و حذف‌شده تصمیم جدا بگیرید
خروجی این مرحله باید یک جدول روشن از نشانی قبلی و وضعیت نهایی آن باشد. قرار نیست همه آدرس‌ها تغییر کنند یا همه صفحات قدیمی نگه داشته شوند. هدف این است که هیچ نشانی مهمی بدون تصمیم رها نشود و کاربر قدیمی به مقصد مرتبط برسد.
آدرس مناسب را حفظ کنید؛ برای تغییر ضروری، مقصد مرتبط تعیین کنید
اگر نشانی صفحه مناسب است، بازطراحی دلیل کافی برای عوض‌کردن آن نیست. وقتی تغییر دائمی لازم است، صفحه قبلی باید در صورت وجود جایگزین مناسب به همان مقصد منتقل شود. برای انتقال دائمی، ریدایرکت سمت سرور با کد ۳۰۱ یا ۳۰۸ راه متداول و توصیه‌شده گوگل است؛ انتخاب و اجرای آن با تیم فنی انجام شود.
مثلاً اگر یک خدمت با نشانی قدیمی به صفحه تازه همان خدمت منتقل شده، ارتباط دو صفحه روشن است. اما فرستادن همه مقاله‌ها و محصولات حذف‌شده به صفحه خانه، جای نقشه انتقال را نمی‌گیرد. اگر دو مطلب ادغام می‌شوند، صفحه مقصد باید نیاز مرتبط آن‌ها را واقعاً پوشش دهد، نه اینکه صرفاً نزدیک‌ترین صفحه از نظر نام باشد.
مقصد نهایی و سیگنال‌های آدرس اصلی را کنترل کنید
ریدایرکت را تا مقصد نهایی بررسی کنید؛ حلقه، چند انتقال متوالی یا رسیدن به صفحه خطا نباید پنهان بماند. لینک‌های داخلی را هم به نشانی نهایی به‌روزرسانی کنید تا کاربر برای پیمودن مسیرهای عادی مدام از ریدایرکت عبور نکند. فایل‌ها و تصاویر جابه‌جاشده نیز در صورت اهمیت باید در نقشه دیده شوند.
برای صفحه واقعاً حذف‌شده و بدون جایگزین مرتبط، پاسخ مناسب حذف، مانند ۴۰۴ یا ۴۱۰، با تصمیم فنی روشن باشد. در صفحات باقی‌مانده، نشانی اصلی نباید به محیط آزمایشی یا صفحه نامرتبط اشاره کند. canonical، لینک داخلی و نقشه سایت باید درباره مقصد مورد نظر هماهنگ باشند؛ ثبت canonical هم تضمین انتخاب همان نشانی توسط گوگل نیست.
نسخه آزمایشی را فقط از نظر ظاهر بررسی نکنید
محیط آزمایشی فرصتی است برای پیدا کردن مشکل پیش از اثرگذاشتن بر مشتری و جست‌وجو. نسخه تازه را با فهرست مرجع مقایسه کنید و نمونه‌ای از هر نوع صفحه را ببینید: خدمت، مقاله، دسته، محصول و صفحه دارای فرم. سالم‌بودن صفحه خانه، سلامت همه الگوها را نشان نمی‌دهد.
محتوا، لینک و اطلاعات سئو باید واقعاً در خروجی وجود داشته باشند
متن اصلی و تیترها را با نسخه قبلی و تغییرهای تأییدشده تطبیق دهید. گاهی برای خلوت‌کردن طرح، توضیح‌های ضروری حذف می‌شوند یا لینک‌ها به عناصر نمایشی بدون مقصد قابل دسترسی تبدیل می‌شوند. برای منو و لینک‌های مهم، وجود پیوند واقعی و قابل دنبال‌کردن بررسی شود؛ شباهت ظاهری به دکمه کافی نیست.
اگر نحوه نمایش به جاوااسکریپت وابسته است، تیم فنی باید دسترسی گوگل به محتوای رندرشده، منابع لازم و نشانی‌های مستقل صفحات را کنترل کند. صرف دیدن محتوا پس از کلیک‌های متعدد در مرورگر کارفرما، بررسی فنی را کامل نمی‌کند. در کنار آن، عنوان سئو، توضیحات، تصاویر و داده‌های ساختاریافته موجود هم نباید بی‌دلیل در قالب تازه ناپدید شوند.
تنظیمات آزمایشی نباید ناخواسته به نسخه اصلی برسند
برای محیط آزمایشی، دسترسی محدود و تنظیمات ایندکس متناسب داشته باشید. گزینه «از موتورهای جست‌وجو درخواست کن محتوای سایت را بررسی نکنند» در تنظیمات خواندن وردپرس، جای کنترل دسترسی به اطلاعات محرمانه را نمی‌گیرد. همچنین وجود این گزینه در پیشخوان، به‌تنهایی وضعیت واقعی خروجی یک معماری اختصاصی را ثابت نمی‌کند.
پیش از انتشار، محدودیت‌ها را طبق هدف هر محیط بازبینی کنید. مسدودسازی خزش با robots.txt با دستور noindex یکسان نیست؛ اگر خزش مسدود باشد، گوگل ممکن است نتواند noindex را ببیند. باقی‌ماندن ناخواسته noindex، رمز محیط آزمایشی یا آدرس آزمایشی در نسخه اصلی باید در کنترل انتشار بررسی شود. برای شناخت تفاوت دسترسی و رتبه، مقاله چرا سایت در گوگل دیده نمی‌شود؟ را بخوانید.
انتشار را با برنامه اجرایی و امکان بازیابی انجام دهید
انتشار لحظه‌ای نیست که فقط فایل قالب تازه فعال شود. باید معلوم باشد چه داده‌ای منتقل می‌شود، چه زمانی تغییرها متوقف می‌شوند، چه کسی نسخه اصلی را کنترل می‌کند و در صورت خرابی جدی چه تصمیمی گرفته می‌شود. این برنامه برای سایت دارای سفارش یا درخواست تازه اهمیت بیشتری دارد.
پشتیبان و انتقال آخرین داده‌ها را جدا برنامه‌ریزی کنید
در ساختار معمول وردپرس، بازیابی کامل به فایل‌ها و پایگاه داده نیاز دارد. نسخه پشتیبان باید قابل استفاده باشد و روش بازیابی آن ترجیحاً در محیط جداگانه بررسی شود. علاوه بر فایل‌ها، نسخه تنظیمات و نقشه ریدایرکت را هم قابل رجوع نگه دارید تا اصلاح فوری به حدس وابسته نباشد.
اگر ساخت نسخه تازه چند هفته طول کشیده، داده محیط آزمایشی ممکن است از سایت اصلی عقب‌تر باشد. جایگزین‌کردن آن بدون هماهنگی می‌تواند سفارش‌ها، درخواست‌ها یا ویرایش‌های تازه را از بین ببرد. برای همگام‌سازی و بازگشت احتمالی، زمان مرجع و روش حفظ داده‌های جدید مشخص شود؛ بازگرداندن پشتیبان قدیمی یک تصمیم بی‌اثر بر داده‌ها نیست.
پس از انتشار، کنترل‌های اصلی را دوباره اجرا کنید
آدرس‌های مهم قبلی، مقصدهای تازه، فرم، تماس و مسیر خرید را روی دامنه اصلی آزمایش کنید. تنظیمات واقعی سرور، کش و سرویس‌های بیرونی ممکن است با محیط آزمایشی تفاوت داشته باشند. وضعیت خزش، ایندکس‌پذیری، نشانی اصلی و نقشه سایت را نیز روی خروجی نهایی بررسی کنید، نه فقط در تنظیمات پیشخوان.
فهرست کنترل تحویل کمک می‌کند مسئولیت‌های این مرحله روشن بماند. در مقاله هنگام تحویل سایت وردپرسی چه چیزهایی باید بررسی کنیم؟ درباره آزمون مسیرها، دریافت دسترسی، پشتیبان و صورت‌جلسه توضیح داده‌ایم. در بازطراحی، تطبیق نسخه تازه با دارایی‌های قبلی را به همان فهرست اضافه کنید.
پس از بازطراحی، چه تغییرهایی را پیگیری کنیم؟
تاریخ انتشار و تغییرهای مهم را ثبت کنید و عملکرد صفحات منتخب را با دوره‌های قابل مقایسه ببینید. همه افت‌ها یک علت ندارند؛ کاهش تقاضا، تغییر ترکیب عبارت‌ها، مسئله ثبت داده یا خطای فنی می‌توانند نمودار مشابهی بسازند. ابتدا دامنه مشکل را پیدا کنید و سپس اقدام کنید.
| نشانه | بررسی اولیه | اقدام بعدی |
|---|---|---|
| افت یک صفحه مهم | محتوا، آدرس، دسترسی و لینک‌های داخلی همان صفحه | رفع تفاوت تأییدنشده و بازبینی نتیجه |
| خطای آدرس‌های قدیمی | تطبیق نقشه انتقال با پاسخ واقعی آدرس | اصلاح مقصد مرتبط یا وضعیت حذف |
| کلیک ثابت و درخواست کمتر | فرم، مسیر تماس و صحت اندازه‌گیری | رفع مشکل مسیر مشتری و کنترل ثبت درخواست |
| افت گسترده در چند نوع صفحه | تغییرهای مشترک قالب، محدودیت ایندکس و خطای سرور | رسیدگی به علت مشترک و تعیین دامنه اثر |
تعداد صفحه ایندکس‌شده یا یک جست‌وجوی دستی، به‌تنهایی معیار سلامت کامل بازطراحی نیست. صفحات مهم، خطاهای جدید، عملکرد جست‌وجو و مسیر جذب مشتری را کنار هم ببینید. برای هر ایراد، مسئول رسیدگی و زمان بازبینی مشخص کنید؛ منتظرماندن بدون بررسی، با فرصت‌دادن به پردازش تغییرهای درست تفاوت دارد.
بازطراحی موفق باید تجربه بهتری بسازد و ادامه کار را قابل مدیریت کند. حفظ محتوای مفید و مسیرهای معتبر، بخشی از کیفیت همین اجراست. برای تعیین دامنه طراحی و پیاده‌سازی متناسب با سایت فعلی، صفحه خدمات طراحی سایت آژانس خلاقیت امین را ببینید.
منابع و مطالعه بیشتر
- راهنمای گوگل برای تغییر آدرس‌ها و انتقال سایت
- ریدایرکت‌های دائمی و موقت در جست‌وجوی گوگل
- راهنمای نشانی اصلی و هماهنگی سیگنال‌های canonical
- دستور noindex و تفاوت آن با مسدودسازی خزش
- مبانی سئوی سایت‌های وابسته به جاوااسکریپت
- تنظیمات خواندن و درخواست جلوگیری از ایندکس در وردپرس
- پشتیبان فایل‌ها و پایگاه داده در مستندات وردپرس