کد 503 در نگهداری وردپرس: چرا 404 به ایندکس آسیب می‌زند

اگر سایت وردپرسی را برای پچ امنیتی یا به‌روزرسانی هسته می‌بندید، کد پاسخ درست ۵۰۳ است، همراه با هدر Retry-After. کد ۴۰۴ به خزنده می‌گوید این آدرس وجود ندارد و ۵۰۰ می‌گوید سرور خراب است. اولی آدرس را از ایندکس بیرون می‌برد، دومی اعتماد خزنده را. کد ۵۰۳ هر دو را کنار می‌زند: می‌گوید «موقتاً نیستم، بعداً برگرد».

تفاوت ۵۰۳ عمدی با ۵۰۳ خرابی

هر دو پاسخ یک کد دارند و معنای کاملاً متفاوتی برای خزنده. یکی تصمیم شماست، دیگری نتیجهٔ خرابی. گوگل این دو را از هم تشخیص نمی‌دهد؛ آنچه فرق می‌کند هدرها و مدت است، نه خود عدد. پس اگر ۵۰۳ می‌دهید و می‌خواهید موقت شمرده شود، باید همان چیزی را بفرستید که موقت بودن را نشان دهد.

نشانه‌های ۵۰۳ عمدی

• زمان بازگشت مشخص است و در هدر Retry-After اعلام شده.
• بدنهٔ پاسخ ثابت و کوتاه است؛ یک صفحهٔ «در حال به‌روزرسانی، چند دقیقهٔ دیگر برگردید».
• پیشخوان مدیریت برای کاربر وارد‌شده باز است و بقیهٔ آدرس‌ها ۵۰۳ می‌گیرند.
• در لاگ خطای PHP هیچ قاتل سروری ثبت نشده است.

نشانه‌های ۵۰۳ خرابی

• بدون Retry-After؛ هیچ زمانی برای تلاش دوباره اعلام نشده.
• بعضی آدرس‌ها ۲۰۰ و بعضی ۵۰۳؛ الگو ندارد.
• خطای مرگبار PHP یا قطع شدن اتصال به پایگاه داده در لاگ دیده می‌شود.
• مصرف منابع سرور بالا رفته و پاسخ‌ها کند شده‌اند.

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

چرا ۴۰۴ یا ۵۰۰ در زمان نگهداری بدترین انتخاب است

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

کد ۴۰۴ معنایش روشن است: «این آدرس دیگر وجود ندارد». خزنده پس از چند بار دیدن این پاسخ، آدرس را از ایندکس بیرون می‌آورد. آن آدرس ممکن است سال‌ها رتبه داشته باشد. برگرداندنش به ایندکس به کشف دوباره، خزش دوباره و بازسازی اعتبار وابسته است و هیچ‌کدام فوری نیستند. اگر با رفتار ۴۰۴ و پیامدهایش آشنا نیستید، راهنمای رفع خطای ۴۰۴ در وردپرس مسیر تشخیص را گام‌به‌گام نشان می‌دهد.

کد ۵۰۰ کمی بهتر است چون موقت شمرده می‌شود، اما همچنان بد است. ۵۰۰ یعنی «سرور خراب است» و هیچ زمانی برای بازگشت اعلام نمی‌کند. خزنده نه می‌داند کِی برگردد، نه دلیلی می‌بیند که آدرس را در اولویت نگه دارد. در عمل، سایت شما از صف خزش عقب می‌افتد؛ همان اتفاقی که بعد از یک روز خرابی هم دیده می‌شود.

کد ۵۰۳ این هزینه را ندارد، به یک شرط: موقت بودنش با هدر اعلام شود و مدت آن کوتاه بماند. تفاوت اینجا سلیقه نیست؛ تفاوت میان «آدرس را نگه دار» و «آدرس را دور بریز» است.

هدر Retry-After و انتخاب عدد درست

خزنده‌ها نمی‌فهمند شما چند ساعت وقت لازم دارید. اگر نگویید، خودشان حدس می‌زنند و حدسشان محافظه‌کارانه است. هدر Retry-After همین را حل می‌کند: یک مقدار زمانی که می‌گوید بعد از آن دوباره تلاش کن.

واحد: ثانیه یا تاریخ HTTP

این هدر دو شکل می‌پذیرد. یک عدد صحیح که تعداد ثانیه‌های انتظار است، یا یک تاریخ به قالب HTTP با منطقهٔ زمانی گرینویچ. شکل ثانیه‌ای ساده‌تر و کم‌خطاتر است؛ همان چیزی که در تست ما هم استفاده شد: Retry-After: 3600.

چه عددی بدهیم

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

یک نکتهٔ دیگر: Retry-After را همراه Cache-Control: no-store بفرستید. اگر پاسخ ۵۰۳ در کش بماند، ممکن است بعد از پایان نگهداری هم به کاربر و خزنده تحویل شود. اگر از یک لایهٔ کش استفاده می‌کنید، قواعد آن را با کش وردپرس و اثر آن بر زمان پاسخ مرور کنید تا صفحهٔ نگهداری در حافظه نماند.

هشدار گوگل: ۵۰۳ چندروزه هم بی‌خطر نیست

در ۲۱ اکتبر ۲۰۲۶، در جریان موج آسیب‌پذیری هستهٔ PHP که بسیاری از سایت‌های وردپرسی را به توقف اضطراری وادار کرد، گوگل یادآوری کرد که در این توقف باید کد ۵۰۳ داد. Search Engine Journal همان روز نوشت: «Google reminded sites to serve a 503 when going offline for PHP patches.»

اما همان گزارش یک هشدار را هم با خود داشت: «Google’s docs warn URLs returning 503s for days may be dropped from the index.» یعنی پاسخ ۵۰۳ برای چند روز، مصونیت نمی‌آورد. این جمله مهم‌ترین بخش ماجراست، چون بیشتر راهنماها فقط نیمهٔ اول را می‌گویند.

نکتهٔ عملی همین‌جاست: ۵۰۳ پنجرهٔ مهلت است، نه چتر محافظ همیشگی. توقف چند ساعته با ۵۰۳ امن است. توقف چندروزه با همان کد، همان ریسک حذف را دارد، فقط با تأخیر. اگر تعمیر طول می‌کشد، بهتر است بخش‌های سالم سایت را برگردانید و فقط بخش در حال تعمیر را ۵۰۳ نگه دارید.

گوگل همچنین یادآوری کرده که ۵۰۳ لازم نیست از داخل PHP بیاید. جان مولر گفته است می‌توان آن را از لایهٔ بیرونی‌تر، با تغییر DNS یا از طریق CDN هم سرو کرد: «Mueller says the 503 can be served outside PHP, through DNS changes or a CDN.» این یعنی لازم نیست برای نگهداری، کد وردپرس را دست بزنید. اگر سایت شما از ابتدا پشت یک لایهٔ کش لبه است، همان لایه می‌تواند پاسخ ۵۰۳ و هدرش را برگرداند؛ توضیح این ساختار در شبکهٔ تحویل محتوا و کش لبه آمده است.

کد آمادهٔ وردپرس بدون افزونه

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

// در فایل wp-config.php
// define( 'SITE_MAINTENANCE', true );  // هنگام نگهداری فعال کنید

// در فایل functions.php قالب فعال
add_action( 'template_redirect', function () {
    if ( ! defined( 'SITE_MAINTENANCE' ) || ! SITE_MAINTENANCE ) {
        return;
    }

    // مدیر وارد‌شده سایت را می‌بیند
    if ( current_user_can( 'manage_options' ) ) {
        return;
    }

    header( 'HTTP/1.1 503 Service Unavailable', true, 503 );
    header( 'Retry-After: 3600' );
    header( 'Cache-Control: no-store, max-age=0' );
    header( 'Content-Type: text/html; charset=utf-8' );

    status_header( 503 );
    nocache_headers();

    echo '<!doctype html><html lang="fa" dir="rtl"><head>'
       . '<meta charset="utf-8"><title>در حال به‌روزرسانی</title></head>'
       . '<body><h1>سایت چند دقیقهٔ دیگر برمی‌گردد</h1>'
       . '<p>در حال به‌روزرسانی امنیتی هستیم. لطفاً بعداً تلاش کنید.</p></body></html>';

    exit;
} );

چند نکته که در اجرا مهم می‌شوند. اول، template_redirect پیش از هر خروجی اجرا می‌شود، پس هدرها سالم می‌رسند. دوم، status_header( 503 ) تنها راه مطمئن برای ثبت کد وضعیت در وردپرس است؛ فرستادن هدر خام به‌تنهایی در بعضی قالب‌ها بازنویسی می‌شود. سوم، شرط مدیر را حذف نکنید؛ وگرنه برای بررسی نتیجهٔ کار به پیشخوان هم دسترسی نخواهید داشت.

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

تست واقعی: سه کد وضعیت روی یک URL

برای دیدن تفاوت، روی یک سرور محلی همان آدرس را سه بار با سه کد مختلف جواب دادیم و هدرهای هر پاسخ را ثبت کردیم. این تست در ۲۶ اکتبر ۲۰۲۶ انجام شد.

خروجی، همان چیزی است که در عمل انتظار داریم. دو پاسخ ۴۰۴ و ۵۰۰ فقط نوع محتوا را اعلام کردند و هیچ اشاره‌ای به زمان تلاش دوباره نداشتند. پاسخ ۵۰۳ سه هدر داشت: نوع محتوا، Retry-After: 3600 و Cache-Control: no-store, max-age=0.

یعنی تفاوت میان این سه پاسخ در بدنهٔ HTML نیست؛ در همان چند خطی است که خزنده می‌خواند. دو پاسخ اول به خزنده هیچ بهانه‌ای برای برگشتن نمی‌دهند. پاسخ سوم می‌گوید یک ساعت دیگر بیا و در این فاصله این پاسخ را جایی ذخیره نکن.

وقتی همین تست را با یک ابزار بررسی هدر روی سایت خودتان تکرار کنید، اگر ۵۰۳ می‌گیرید ولی Retry-After نمی‌بینید، بدانید که پاسخ نگهداری‌تان ناقص است. اگر با کد ۵۰۳ هم مواجه نشدید، یعنی سایت هنوز پاسخ پیش‌فرض سرور یا قالب را می‌فرستد. برای دیدن بقیهٔ کدهای وضعیت و مسیر رفعشان، فهرست راهنماهای رفع خطای وردپرس نقطهٔ شروع خوبی است.

بازگشت از حالت نگهداری

لحظه‌ای که پچ تمام شد، کار تمام نشده است. آنچه بعد از بازگشت انجام می‌دهید تعیین می‌کند که پاسخ ۵۰۳ موقت مانده باشد یا به یک وقفهٔ طولانی تبدیل شود.

بعد از بازگشت چه چیزی را چک کنیم

1. صفحهٔ اصلی و یک مقالهٔ نمونه را باز کنید و کد ۲۰۰ را ببینید، نه ۵۰۳.
2. مطمئن شوید Retry-After دیگر در پاسخ نیست.
3. نقشهٔ سایت را باز کنید و ۲۰۰ بودن آن را بررسی کنید.
4. در ابزار بازرسی آدرس، یک بار درخواست ایندکس بدهید؛ نه چند بار پشت‌سرهم.
5. دو روز بعد، گزارش خزش را ببینید و ببینید خزنده برگشته است.

درخواست ایندکس مکرر کمک نمی‌کند و می‌تواند به عنوان رفتار مزاحم دیده شود. یک بار کافی است. به همان اندازه، اگر پاسخ ۵۰۳ چند روز طول کشیده، انتظار نداشته باشید که رتبه‌ها در همان روز اول برگردند؛ بازگشت به زمان نیاز دارد و عجله در این مرحله فقط منابع را جابه‌جا می‌کند.