لینک‌ها بعد از انتقال وردپرس خراب شده‌اند؛ رفع 404، Permalink و Redirect

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

پاسخ سریع: یک URL خراب را با curl -I آزمایش و همه Redirectها و Status نهایی را ثبت کنید. اگر صفحه اصلی باز می‌شود اما همه نوشته‌ها 404 هستند، ساختار پیوند یکتا و Rewrite وب‌سرور را بررسی کنید. اگر فقط بعضی لینک‌ها خراب‌اند، دامنه قدیمی، پیشوند پوشه، Slug تغییرکرده یا محتوای مفقود را پیدا کنید. URL واقعاً منتقل‌شده را با Redirect دائمی به نزدیک‌ترین جایگزین بفرستید و برای محتوای واقعاً حذف‌شده پاسخ 404 یا 410 درست بدهید.

پیش از هر تغییر، خرابی را طبقه‌بندی کنید

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

curl -I https://www.example.com/sample-page/
curl -IL --max-redirs 10 https://www.example.com/sample-page/

Status، هدرهای Location، Host، Scheme، Path و نوع پاسخ را ثبت کنید. مشخص کنید Body صفحه 404 وردپرس، خطای Proxy یا محتوایی نامرتبط است. پیش از ویرایش، از تنظیم وب‌سرور و Redirectها نسخه نگه دارید.

از الگوی خرابی برای محدودکردن علت استفاده کنید

• صفحه اصلی سالم و همه نوشته‌ها 404: Permalink یا Rewrite محتمل‌ترین علت است.
• فقط لینک‌های دامنه قدیمی خراب: URL ذخیره‌شده، DNS، Virtual Host یا Redirect مهاجرت را بررسی کنید.
• فقط یک Content Type خراب: ثبت Rewrite مربوط به Post Type یا Taxonomy ممکن است غیرفعال یا تغییرکرده باشد.
• فقط Media خراب: انتقال فایل و Upload Path را با راهنمای تصاویر مفقود بررسی کنید.
• جابجایی میان HTTP/HTTPS یا نسخه‌های www: Redirect Canonical یا تشخیص Scheme پشت Proxy تعارض دارد.
• چرخش میان چند URL: پیش از تغییر Permalink، Redirect Chain یا Loop را پیدا کنید.

URLهای وردپرس و ساختار پیوند یکتا را تأیید کنید

WordPress Address، Site Address و ساختار Permalink را با URL عمومی مورد انتظار مقایسه کنید. با WP-CLI می‌توان بدون تغییر وضعیت آن‌ها را خواند:

wp option get home
wp option get siteurl
wp option get permalink_structure

در نصب Subdirectory ممکن است home و siteurl عمداً متفاوت باشند. پیش از شناخت معماری آن‌ها را یکسان نکنید. Constantهای پیکربندی یا Bootstrap محیطی که مقدار دیتابیس را Override می‌کنند نیز بررسی شوند.

Rewrite را در لایه درست تعمیر کنید

وردپرس URLهای خوانا را با Rewrite Rule به Query داخلی تبدیل می‌کند. مستند رسمی wp rewrite flush بازسازی این Ruleها را توضیح می‌دهد. ابتدا تنظیم فعلی را نگه دارید و فعال‌بودن Theme و Pluginهای لازم را تأیید کنید؛ Custom Post Typeها هنگام اجرا Route خود را ثبت می‌کنند.

wp rewrite flush

Flush فقط Ruleهای وردپرس را تازه می‌کند؛ Server Block اشتباه Nginx، Apache Module مفقود، مسیر قدیمی Proxy یا صفحه ناموجود را تعمیر نمی‌کند. اجرای تکراری آن در هر درخواست راه‌حل نیست.

رفتار Apache و Nginx را از هم جدا کنید

در Apache بررسی کنید Virtual Host اجازه Override مناسب دارد و بلوک Rewrite وردپرس در Document Root درست قرار گرفته است. هنگام بازیابی، Ruleهای امنیتی و برنامه‌ای نامرتبط را حفظ کنید. Hard Flush در WP-CLI فقط در شرایط پشتیبانی‌شده Single Site و با تنظیم لازم می‌تواند .htaccess را تغییر دهد.

Nginx از .htaccess استفاده نمی‌کند. Fallback مسیر باید در پیکربندی مدیریت‌شده Server باشد و وردپرس نمی‌تواند آن فایل را ویرایش کند. راهنمای رسمی Nginx وردپرس این تفاوت را توضیح می‌دهد. تنظیم را با Workflow استقرار موجود Validate و Reload کنید؛ Rule آپاچی را در Nginx نچسبانید.

تغییر پوشه و پیشوند مسیر را بررسی کنید

انتقال از /wordpress/ به ریشه دامنه یا برعکس، لینک‌هایی با Prefix منسوخ باقی می‌گذارد. Path درخواست را با Route Base جدید، منو، Canonical و Assetهای تولیدشده مقایسه کنید. مطمئن شوید Reverse Proxy یک Prefix را دوبار اضافه یا حذف نمی‌کند.

برای URL عمومی منتقل‌شده Redirect صریح بسازید. پیش از استفاده از Regex گسترده، Pathهای نمونه، Query String، نویسه‌های Encodeشده و Routeهای مدیریتی مستثنا را آزمایش کنید.

دامنه‌های قدیمی را امن پیدا کنید

Host قدیمی ممکن است در محتوای نوشته، Navigation، Widget، Theme Setting، Page Builder یا Optionهای Serialized مانده باشد. با Dry Run سازگار با Serialization شروع کنید:

wp search-replace 'https://old.example' 'https://new.example' --all-tables-with-prefix --dry-run

پیش از Write، Tableها و تعداد Match را مرور کنید. HTTP، HTTPS، www، دامنه Staging، URL escaped و Prefix خالی از Host را جدا جست‌وجو کنید. روی داده Serialized جایگزینی SQL خام انجام ندهید. راهنمای انتقال دامنه Workflow کامل DNS، TLS، Canonical و Replacement را شرح می‌دهد.

Redirect را فقط برای منبع منتقل‌شده به‌کار ببرید

URL قدیمی دارای جایگزین روشن باید با Redirect دائمی سمت سرور به همان مقصد مرتبط برسد. مسیر را کوتاه نگه دارید: URL قدیمی، در صورت نیاز یک مرحله Canonical و سپس صفحه نهایی با 200. لینک‌های داخلی را نیز اصلاح کنید تا کاربر و Crawler دائماً به Redirect وابسته نباشند.

راهنمای Redirect گوگل برای تغییر دائمی URL از Redirect دائمی استفاده می‌کند. همه URLهای مفقود را به صفحه اصلی نفرستید؛ مقصد نامرتبط ممکن است Soft 404 تلقی شود و پاسخ مفیدی به کاربر نمی‌دهد.

برای محتوای حذف‌شده Status صادقانه بدهید

اگر URL هرگز وجود نداشته یا عمداً بدون جایگزین معادل حذف شده، پاسخ واقعی 404 یا 410 بدهید. صفحه 404 سفارشی می‌تواند مسیرهای مفید پیشنهاد کند، اما HTTP Status آن باید همچنان درست باشد. راهنمای خطاهای Crawl گوگل صفحه مفقود را از صفحه منتقل‌شده جدا و درباره پاسخ Soft Error هشدار می‌دهد.

پیش از اعلام حذف، تفاوت حروف، سیاست Trailing Slash، Percent Encoding، پیشوند زبان، تاریخ، Category Base و وضعیت Draft یا Private را کنترل کنید.

Redirect Loop را مرحله‌ای تشخیص دهید

همه Hopها را فهرست و مالک هرکدام را مشخص کنید: CDN، Load Balancer، وب‌سرور، Security Plugin، WordPress یا کد برنامه. Loopهای رایج شامل HTTP-to-HTTPS در Edge و برگشت HTTPS-to-HTTP در وردپرس، Ruleهای رقیب www و نرمال‌سازی تکراری Trailing Slash هستند.

تشخیص HTTPS و Trusted Proxy Header را در مرز مناسب اصلاح کنید. برای پنهان‌کردن Loop، TLS Enforcement را سراسری خاموش نکنید. هر بار فقط یک مالک Redirect را تغییر دهید و Rollback Copy داشته باشید.

Custom Post Type، Taxonomy و Pluginها را بررسی کنید

اگر نوشته عادی سالم است اما محصول، Portfolio، Course یا Route ترجمه‌شده خراب است، فعال‌بودن و سازگاری افزونه یا قالب ثبت‌کننده آن Route را تأیید کنید. Slug و Rewrite Setting آن را با مبدأ مقایسه کنید. پس از بازگرداندن Registration فقط یک‌بار Ruleها را Flush کنید؛ Flush هنگام غیرفعال‌بودن Component نمی‌تواند Route آن را بسازد.

در سایت چندزبانه هر Language Prefix را تست کنید و زبان مقصد لینک را کنترل کنید. در Multisite نیز Network Path، Mapped Domain و Routing هر Site را بررسی کنید و فرض Single Site به‌کار نبرید.

لینک‌های داخلی و Navigation را اصلاح کنید

Redirect Map درست نباید برای همیشه معماری لینک داخلی سایت شود. URLهای صریح را در محتوای نوشته، Menu، Reusable Block، Widget، قالب Page Builder، Breadcrumb، XML Sitemap و Navigation ساخت‌یافته اصلاح کنید.

از Navigation و صفحات پرترافیک شروع کنید. راهنمای انتقال بدون افت سئو جایگاه Crawl Comparison، Canonical و Sitemap را در ارزیابی پس از مهاجرت توضیح می‌دهد.

Cache و رفتار CDN را در نظر بگیرید

CDN یا Reverse Proxy ممکن است Redirect و پاسخ 404 را Cache کند. پاسخ عمومی را با تست مجاز Origin مقایسه و هدرهای Age، Cache Status و Location را بررسی کنید. ابتدا یک URL خراب را Purge و نتیجه را تأیید کنید؛ سپس درباره Scope وسیع‌تر تصمیم بگیرید.

پس از اصلاح Route زیرساختی فقط Cache برنامه یا صفحه مرتبط را پاک کنید. پاک‌کردن Cache نمی‌تواند Rewrite مفقود بسازد یا محتوای حذف‌شده را برگرداند.

تعمیر را با Crawl کنترل‌شده اعتبارسنجی کنید

1. URL خراب اولیه را بدون اتکا به Browser Cache دوباره آزمایش کنید.
2. یک نوشته، برگه، دسته، Pagination، Search، Media و هر Content Type سفارشی را بررسی کنید.
3. HTTP/HTTPS، Host ترجیحی، Trailing Slash و Language Prefixها را تست کنید.
4. لینک‌های داخلی را Crawl و 3xx، 4xx، 5xx، Chain و Loop باقی‌مانده را طبقه‌بندی کنید.
5. URLهای قدیمی مهم را با Redirect Map مقایسه و مقصد نهایی را تأیید کنید.
6. در طول زمان Access Log و گزارش ابزارهای جست‌وجو را ببینید؛ خطاهای تاریخی فوراً ناپدید نمی‌شوند.

اشتباه‌های رایج

• ذخیره مکرر Permalink بدون بررسی وب‌سرور
• جایگزینی URLهای Serialized با SQL خام
• Redirect همه 404ها به صفحه اصلی
• چیدن Redirectهای CDN، Server، Plugin و WordPress برای یک Rule
• نادیده‌گرفتن Custom Post Type، Language Prefix یا Multisite Path
• Purge همه Cacheها پیش از اثبات لایه خراب
• تغییر Slug برای حل مشکل Routing

چه زمانی کمک تخصصی مناسب است؟

Redirect Inventory بزرگ، شبکه Multisite، Routing چندزبانه، Custom Post Type یا چند لایه Proxy، ریسک اصلاح انبوه را بالا می‌برد. سرویس انتقال سایت وردپرس می‌تواند مجموعه URL قدیم و جدید را مقایسه، لایه خراب را جدا و Redirectها را پیش از تغییر محدود اعتبارسنجی کند.

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

چرا صفحه اصلی باز می‌شود اما همه نوشته‌ها 404 هستند؟

سرور عمومی در دسترس است اما Rewrite مربوط به URLهای خوانا ممکن است مفقود، غیرفعال یا متصل به Document Root اشتباه باشد. Permalink و پیکربندی درست Apache یا Nginx را بررسی کنید.

ذخیره صفحه Permalinks همیشه خطای 404 مهاجرت را حل می‌کند؟

خیر؛ ممکن است Rule وردپرس را تازه کند، اما Server Block خراب Nginx، Plugin غیرفعال Custom Post Type، Prefix اشتباه Proxy یا محتوای ناموجود را تعمیر نمی‌کند.

همه 404های قدیمی را به صفحه اصلی Redirect کنیم؟

خیر؛ URL منتقل‌شده را به نزدیک‌ترین جایگزین مرتبط هدایت کنید. وقتی منبع معادل وجود ندارد پاسخ واقعی 404 یا 410 بدهید.

چرا لینک تعمیرشده هنوز Redirect قدیمی را نشان می‌دهد؟

Browser، Page Cache، Reverse Proxy یا CDN ممکن است پاسخ قبلی را نگه دارد. هدر هر لایه را مقایسه و پس از تأیید Origin، محدودترین Cache مرتبط را Invalidate کنید.