خطای 500 Internal Server Error در وردپرس به‌تنهایی علت خرابی را مشخص نمی‌کند؛ سرور فقط می‌گوید درخواست را نتوانسته پردازش کند. اگر منشأ مشکل PHP Fatal Error باشد، با فعال‌سازی موقت ثبت خطا در wp-config.php، بررسی debug.log و تطبیق زمان خطا با افزونه یا قالب می‌توان علت را پیدا کرد. پیش از هر تغییر از فایل‌ها و دیتابیس نسخه پشتیبان بگیرید و نمایش خطا به بازدیدکننده را خاموش نگه دارید.
خطای 500 چه زمانی از PHP است؟
HTTP 500 می‌تواند از PHP، وب‌سرور، تنظیمات .htaccess، مجوز فایل‌ها، کمبود منابع یا سرویس‌های پشت وب‌سرور ایجاد شود. بنابراین وجود 500 به‌معنای قطعی بودن PHP Fatal نیست. ابتدا زمان رخداد، URL خراب، تغییرات اخیر و لاگ وب‌سرور را یادداشت کنید. اگر فقط درخواست‌های بیرونی سایت خطا دارند، بررسی اتصال و DNS نیز مهم است؛ برای تفکیک این حالت از خطای HTTP API، راهنمای عیب‌یابی cURL error 28 و Loopback وردپرس را ببینید.
پیش‌نیازهای عیب‌یابی امن
به File Manager یا SFTP و فایل wp-config.php دسترسی داشته باشید. بهتر است ابتدا روی محیط Staging بازتولید کنید. از wp-config.php، پوشه wp-content و دیتابیس بکاپ بگیرید. فایل لاگ ممکن است مسیرها، نام افزونه‌ها و اطلاعات حساس را افشا کند؛ هرگز آن را عمومی منتشر نکنید.
فعال کردن موقت WP_DEBUG_LOG بدون نمایش خطا
در فایل wp-config.php و قبل از خط /* That's all, stop editing! */، مقادیر زیر را قرار دهید. اگر از قبل تعریف شده‌اند، همان تعریف را ویرایش کنید؛ تعریف تکراری نسازید.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );طبق مستند رسمی Debugging وردپرس، مقدار WP_DEBUG_LOG بدون فعال بودن WP_DEBUG عمل نمی‌کند. این تنظیم معمولاً پیام‌ها را در wp-content/debug.log ثبت می‌کند. برای سایت Production فقط در بازه کوتاه و کنترل‌شده عیب‌یابی فعال کنید؛ اگر میزبانی اجازه می‌دهد، مسیر لاگ را به محل غیرعمومی منتقل کنید.
بازتولید خطا و پیدا کردن PHP Fatal
یک‌بار همان صفحه خراب را باز کنید، سپس در File Manager یا SSH آخرین خطوط لاگ را بررسی کنید. دستور زیر را فقط با دسترسی مجاز و مسیر صحیح اجرا کنید:
tail -n 80 wp-content/debug.logبرای پایش لحظه‌ای، در صورت نیاز:
tail -f wp-content/debug.logنمونه ساختگیِ صرفاً آموزشی از شکل پیام خطا:
[06-Nov-2026 08:00:00 UTC] PHP Fatal error: Uncaught Error: Call to undefined function example_function() in /path/wp-content/plugins/example-plugin/file.php:42در این مثال مسیر افزونه و شماره خط سرنخ‌اند، نه اثبات قطعی علت. خطاهای Allowed memory size exhausted، Call to undefined function و Uncaught Error به بررسی‌های متفاوتی نیاز دارند. پیام‌های Notice و Warning لزوماً علت HTTP 500 نیستند؛ زمان و درخواست را تطبیق دهید.
اگر فایل debug.log ساخته نشد
مطمئن شوید تنظیمات در فایل درست و بدون تعریف تکراری قرار گرفته‌اند، مسیر wp-content برای پردازش PHP قابل نوشتن است و خطا پس از فعال‌سازی دوباره رخ داده است. برخی خطاها قبل از بوت‌استرپ وردپرس اتفاق می‌افتند و فقط در PHP error log یا لاگ وب‌سرور ثبت می‌شوند. در cPanel معمولاً بخش Errors و امکانات PHP Selector/مدیریت لاگ، بسته به تنظیمات میزبان، کمک می‌کند. از ایجاد مجوزهای ناامن مثل 777 خودداری کنید.
اگر در هاست اشتراکی به لاگ PHP، تنظیمات نسخه PHP یا محدودیت منابع دسترسی کافی ندارید، این محدودیت را با پشتیبانی میزبان بررسی کنید؛ هنگام ارزیابی جابه‌جایی میزبانی، پلن‌های هاست وان‌سرور را از نظر امکانات مدیریت PHP و منابع موردنیاز سایت مقایسه کنید. تغییر هاست به‌تنهایی خطای افزونه یا کد معیوب را اصلاح نمی‌کند.
ایزوله کردن افزونه، قالب و منابع
افزونه‌ها
اگر لاگ به یک افزونه مشخص اشاره دارد، ابتدا سازگاری آن با نسخه PHP و وردپرس را بررسی کنید. پس از بکاپ و در صورت امکان روی Staging، فقط همان افزونه را موقتاً غیرفعال و دوباره تست کنید. در صورت نداشتن داشبورد، تغییر نام موقت پوشه همان افزونه از طریق SFTP می‌تواند به تشخیص کمک کند؛ این کار ممکن است قابلیت‌های سایت را قطع کند و باید مسیر بازگشت داشته باشد.
قالب و حافظه
اگر مسیر Fatal به قالب مربوط است، با قالب پیش‌فرض سازگار در محیط آزمایشی بررسی کنید. برای خطای کمبود حافظه، مصرف واقعی PHP و سقف میزبان را بسنجید؛ افزایش بی‌محابای WP_MEMORY_LIMIT بدون توجه به سقف memory_limit سرور راه‌حل تضمینی نیست. اگر هم‌زمان خطای محدودیت منابع هاست می‌بینید، مقاله تشخیص خطای 508 و محدودیت EP و حافظه CloudLinux مسیر جداگانه‌ای برای بررسی ظرفیت ارائه می‌کند.
اگر علت 500 در PHP نبود
لاگ‌های Apache/LiteSpeed/NGINX، خطای پیکربندی .htaccess، مالکیت و مجوز فایل‌ها، PHP-FPM و پاسخ Upstream را بررسی کنید. در صورت مشاهده خطاهای SSL یا CA Bundle در درخواست‌های خارجی، راهنمای رفع cURL error 60 و بررسی CA Bundle در وردپرس را دنبال کنید؛ آن خطا با هر HTTP 500 یکسان نیست.
تأیید رفع مشکل و Rollback
پس از اصلاح عامل مشخص‌شده، صفحه اصلی، صفحه مشکل‌دار، ورود مدیر و یک مسیر مهم مثل سبد خرید را تست کنید. کد HTTP را بررسی کنید:
curl -I https://example.com/problem-page/این دستور پاسخ HEAD را نشان می‌دهد؛ بعضی سایت‌ها برای HEAD رفتار متفاوت دارند، بنابراین تست مرورگر یا GET را هم انجام دهید. بعد از پایان تشخیص، مقادیر را به حالت امن بازگردانید:
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );این‌ها باید جایگزین تعاریف قبلی شوند، نه اینکه کنار آن‌ها تکرار شوند. فایل لاگ را پس از بررسی و نگهداری امن حذف یا به مسیر محافظت‌شده منتقل کنید. اگر تغییر افزونه، قالب یا پیکربندی نتیجه نداد، با بکاپ و یادداشت تغییرات به وضعیت پیشین برگردید؛ هرگز بدون تشخیص، همه افزونه‌ها یا فایل‌های هسته را دسته‌جمعی حذف نکنید.