اگر صفحهٔ اصلی باز می‌شود اما نوشته‌های وردپرس خطای 404 می‌دهند، ابتدا بازشدن همان نوشته با شناسه را بررسی کنید و سپس یک‌بار تنظیمات پیوند یکتا را بدون تغییر ساختار ذخیره کنید. اگر مشکل باقی ماند، مسیر عیب‌یابی به وب‌سرور بستگی دارد: در Apache قوانین rewrite و فایل .htaccess مهم‌اند؛ در Nginx باید پیکربندی server بررسی شود، چون Nginx فایل htaccess را نمی‌خواند. اگر تنها یک نوشته خراب است، پیش از تنظیمات سرور، وضعیت انتشار و نشانی همان نوشته را بررسی کنید.
رفع خطای 404 نوشته‌های وردپرس با ریدایرکت‌کردن همهٔ نشانی‌ها به صفحهٔ اصلی انجام نمی‌شود. هدف این است که هر نشانی درست، محتوای خودش را نمایش دهد و نشانی واقعاً ناموجود همچنان پاسخ مناسب بگیرد. این راهنما برای وردپرس تک‌سایتی نوشته شده است؛ نصب زیرپوشه، Multisite و پیکربندی‌های مدیریت‌شده ممکن است قواعد متفاوتی داشته باشند.
۱. مشخص کنید 404 برای همهٔ نوشته‌هاست یا چند نشانی
سه نمونه انتخاب کنید: یک نوشتهٔ قدیمی، یک نوشتهٔ تازه و یک برگه. نشانی را از دکمهٔ «نمایش» در ویرایشگر بردارید، نه از لینک ذخیره‌شدهٔ قدیمی. وضعیت باید منتشرشده و دسترسی عمومی باشد؛ پیش‌نویس، نوشتهٔ خصوصی یا مطلبی با زمان انتشار آینده قرار نیست برای بازدیدکنندهٔ ناشناس مانند مطلب عمومی باز شود. آزمون را در پنجرهٔ ناشناس نیز تکرار کنید.
اگر فقط یک مطلب مشکل دارد، نامک جدید، انتقال به زباله‌دان، تغییر دسته در ساختار وابسته به دسته و لینک اشتباه را بررسی کنید. اگر همهٔ نشانی‌های خوانا خراب‌اند اما صفحهٔ اصلی کار می‌کند، قواعد ارسال درخواست به وردپرس محتمل‌ترند. بازبودن صفحهٔ اصلی سلامت همهٔ مسیرها را ثابت نمی‌کند؛ این صفحه ممکن است حتی از کش ارائه شده باشد.
| نشانه | آزمون | اقدام بعدی |
|---|---|---|
| تنها یک نوشته 404 می‌دهد | نمایش از ویرایشگر و بررسی انتشار و نامک | لینک اشتباه یا تغییر نشانی همان مطلب را اصلاح کنید. |
| همهٔ نوشته‌ها خراب‌اند، شناسه باز می‌شود | مقایسهٔ نشانی خوانا با ?p=ID | پیوند یکتا و rewrite وب‌سرور را بررسی کنید. |
| خطا پس از انتقال هاست شروع شده | بررسی مسیر نصب و وب‌سرور مقصد | قواعد متناسب با نصب فعلی را تطبیق دهید. |
| مبدأ سالم است، نشانی عمومی خراب است | مقایسهٔ کنترل‌شدهٔ پاسخ مبدأ و CDN | کش همان URL یا قانون مسیر CDN را بررسی کنید. |
| فقط محصولات یا نوع محتوای خاص خراب است | بررسی افزونهٔ ثبت‌کننده و تداخل نامک | در محیط آزمایشی علت قواعد همان نوع محتوا را پیدا کنید. |
۲. نشانی خوانا را با شناسهٔ نوشته مقایسه کنید
شناسه را می‌توان در نشانی صفحهٔ ویرایش نوشته دید؛ مثلاً post=123. برای نوشتهٔ منتشرشدهٔ نمونه، دو نشانی زیر را در همان دامنه مقایسه کنید. example.com و عدد 123 نمونهٔ آموزشی‌اند و باید با اطلاعات سایت خودتان عوض شوند:
https://example.com/sample-post/
https://example.com/?p=123اگر نشانی مبتنی بر شناسه محتوا را نشان می‌دهد و نشانی خوانا 404 است، بازنویسی مسیر مظنون مهمی است. این آزمون حکم نهایی نیست؛ وردپرس ممکن است نشانی شناسه را به نشانی اصلی ریدایرکت کند. در ابزار Network مرورگر، زنجیرهٔ درخواست را ببینید تا معلوم شود محتوای نهایی واقعاً با چه وضعیتی برگشته است. انواع نشانی در مستند پیوندهای یکتای وردپرس توضیح داده شده‌اند.
شکل ظاهری صفحه به‌تنهایی کد پاسخ را تعیین نمی‌کند. در ابزار توسعهٔ مرورگر، Network را باز کنید، صفحه را بارگیری و درخواست اصلی document را انتخاب کنید. Status Code و نشانی نهایی را ثبت کنید. طبق تعریف 404 در MDN، این پاسخ یعنی منبع درخواستی پیدا نشده است؛ یک تصویر بزرگ «404» در صفحه‌ای با وضعیت 200 آزمون کافی برای این نتیجه نیست.
۳. پیوند یکتا را یک‌بار و بدون تغییر ساختار ذخیره کنید
از پیشخوان وارد «تنظیمات ← پیوندهای یکتا» شوید. از ساختار فعلی یادداشت یا تصویر بگیرید و بدون عوض‌کردن گزینه‌ها، یک‌بار «ذخیرهٔ تغییرات» را بزنید. سپس دو نمونه از نوشته‌های خراب را دوباره آزمایش کنید. هدف بازسازی قواعد وردپرس است؛ تغییر ساختار سایت زنده به «نام نوشته» یا «ساده» برای آزمایش، ممکن است مجموعهٔ بزرگی از نشانی‌های فعلی را عوض کند.
اگر همان یک بار مشکل را حل کرد، آخرین تغییر افزونه، قالب یا انتقال سایت را ثبت کنید. ذخیره‌کردن روزانه یا افزودن flush_rewrite_rules() به کدی که در هر درخواست اجرا می‌شود، راه‌حل پایدار نیست. مرجع توسعهٔ وردپرس تصریح می‌کند که بازسازی قواعد عملیات پرهزینه‌ای است و باید هنگام نیاز انجام شود. اگر ذخیره‌سازی اثری نداشت، سراغ لایهٔ بعد بروید.
۴. در Apache فایل htaccess و اجازهٔ اجرای rewrite را بررسی کنید
ابتدا از پشتیبانی بپرسید پردازش نهایی درخواست وردپرس را کدام وب‌سرور انجام می‌دهد. نام Server در پاسخ HTTP همیشه معماری کامل سرویس را نشان نمی‌دهد؛ ممکن است Nginx جلوی Apache باشد. اگر Apache مسئول rewrite است، فایل مخفی .htaccess را در مسیر صحیح نصب پیدا کنید. پیش از ویرایش، نسخهٔ پشتیبان بگیرید و قوانین امنیتی، کش و ریدایرکت موجود را نگه دارید.
برای نصب تک‌سایتی در ریشهٔ دامنه، نمونهٔ پایهٔ رسمی به شکل زیر است. این قطعه جایگزین کل فایل شما نیست؛ فقط برای مقایسهٔ بخش WordPress ارائه می‌شود. برای نصب زیرپوشه یا شبکه از همین نسخه بدون تطبیق استفاده نکنید:
# BEGIN WordPress
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPressنمونه در راهنمای Apache و htaccess وردپرس آمده است. بخش‌های خارج از نشانگرهای WordPress را پاک نکنید. اگر پیشخوان اعلام کرد فایل قابل نوشتن نیست، دسترسی 777 ندهید؛ از مدیر هاست بخواهید مالکیت و مجوز مناسب را بررسی و بخش لازم را با حفظ سایر قواعد اصلاح کند.
وجود فایل صحیح کافی نیست. ماژول mod_rewrite باید بارگذاری شده باشد و تنظیم Directory اجازهٔ قواعد موردنیاز را بدهد. طبق مستند htaccess آپاچی، با AllowOverride None فایل نادیده گرفته می‌شود. مدیر سرور باید اجازهٔ مناسب را برای همان مسیر بررسی کند؛ تغییر گستردهٔ کل سرور به AllowOverride All برای رفع یک سایت ضروری نیست. روی هاست اشتراکی، این کار در سطح دسترسی کاربر عادی نیست.
۵. در Nginx مسیر درخواست باید به index.php برسد
Nginx تنظیمات htaccess را اجرا نمی‌کند. بنابراین ساختن یا بازنویسی مکرر این فایل روی نصب مبتنی بر Nginx تغییری در مسیر درخواست ایجاد نخواهد کرد. در پیکربندی متداول تک‌سایتیِ ریشه، مدیر server block مربوط به همین دامنه را با منطق زیر مقایسه می‌کند:
location / {
try_files $uri $uri/ /index.php?$args;
}این قطعه می‌گوید ابتدا فایل یا پوشهٔ موجود بررسی شود و در غیر این صورت درخواست به ورودی وردپرس برسد. راهنمای Nginx وردپرس و مرجع try_files در Nginx مبنای این الگو هستند. این فقط بخشی از پیکربندی است؛ بخش PHP-FPM، مسیر root، قواعد فایل‌های حساس و کنترل‌پنل باید حفظ شوند. اگر location / از قبل وجود دارد، یک بخش تکراری به انتهای فایل اضافه نکنید.
مدیر باید مطمئن شود فایل صحیح و دامنهٔ صحیح را ویرایش کرده است. بعد از گرفتن نسخهٔ پشتیبان و اعمال تغییر محدود، ابتدا صحت پیکربندی را با فرمان زیر بررسی کند:
sudo nginx -tفقط در صورت موفقیت آزمون، تنظیمات با روش استاندارد همان سرویس reload شود؛ در نصب متداول دارای systemd معمولاً sudo systemctl reload nginx استفاده می‌شود. اگر خطا گزارش شد، reload نکنید و همان خطا را رفع کنید. پارامتر آزمون در مستند فرمان‌های Nginx توضیح داده شده است. در سرویس مدیریت‌شده، تغییر فایل تولیدشده توسط پنل ممکن است بازنویسی شود؛ از محل تنظیمات سفارشی همان سرویس استفاده کنید.
۶. کش، CDN و قواعد افزونه را از هم جدا کنید
پس از اصلاح علت، کش همان نشانی‌های درگیر را پاک کنید. راهنمای کش HTTP در MDN توضیح می‌دهد که کش می‌تواند پاسخ ذخیره‌شده را دوباره ارائه کند. گاهی نسخهٔ قدیمی 404 در لایهٔ کش باقی می‌ماند؛ پاک‌کردن همهٔ کش‌ها پیش از تشخیص، فقط شواهد را کم می‌کند. مدیر می‌تواند پاسخ مبدأ و مسیر عمومی را به شکل کنترل‌شده مقایسه کند. برای این کار لازم نیست DNS سایت زنده را برای همه تغییر دهید یا IP مبدأ را عمومی کنید. نتیجهٔ آزمایش را همراه هدرهای پاسخ و زمان ثبت کنید.
اگر فقط یک نوع محتوا مانند محصولات 404 می‌شود، افزونهٔ ثبت‌کنندهٔ آن نوع محتوا و تداخل نامک را بررسی کنید. غیرفعال‌کردن هم‌زمان همهٔ افزونه‌ها روی فروشگاه فعال می‌تواند پرداخت یا نمایش محصول را مختل کند. تغییرات را در نسخهٔ آزمایشی، یکی‌یکی و با مسیر برگشت بررسی کنید؛ پس از اصلاح علت ثبت قواعد، همان یک بازسازی موردنیاز کافی است.
۷. یک مثال و معیار تأیید رفع خطا
فرض کنید سایت از هاست Apache به VPS مبتنی بر Nginx منتقل شده است. صفحهٔ اصلی و فایل‌های تصویر سالم‌اند، اما نشانی نوشته‌ها 404 است. فایل htaccess هم از نسخهٔ قبلی منتقل شده است. در این مثال آموزشی، بازبودن فایل‌ها با نرسیدن مسیر نوشته به index.php سازگار است؛ بررسی server block و try_files مقدم بر نصب افزونهٔ ریدایرکت است.
پس از اصلاح، سه نشانی معتبر را در حالت ناشناس آزمایش کنید: نوشته، برگه و آرشیو مرتبط. هرکدام باید محتوای صحیح و پاسخ موردانتظار بدهد. یک مسیر ساختگی نیز بررسی کنید تا همچنان 404 واقعی باشد. اگر نشانی مطلب عمداً تغییر کرده، برای نشانی قدیمی ریدایرکت مشخص به جایگزین مرتبط تنظیم کنید؛ همهٔ خطاها را به خانه نفرستید. برای بررسی ساختار سایت از خدمات سلامت سایت آفاق هاست و برای تنظیمات وب‌سرور از مدیریت سرور کمک بگیرید. در انتخاب هاست لینوکس نیز پشتیبانی از معماری و قواعد وردپرس را روشن کنید.
پرسش‌های متداول
چرا فقط صفحهٔ اصلی وردپرس باز می‌شود؟
این الگو می‌تواند از قواعد پیوند یکتا یا مسیر وب‌سرور باشد، به‌ویژه وقتی همهٔ نوشته‌های منتشرشده خراب‌اند. ابتدا دامنهٔ مشکل را مشخص کنید؛ اگر فقط یک URL خراب است، نامک و وضعیت همان محتوا را بررسی کنید.
آیا برای رفع 404 باید htaccess را حذف کنم؟
حذف کل فایل ممکن است قواعد امنیتی، کش و ریدایرکت را از بین ببرد. ابتدا نسخهٔ پشتیبان بگیرید و فقط بخش لازم را مقایسه و اصلاح کنید. در Nginx نیز این فایل راه‌حل مسیر‌دهی نیست.
بعد از ذخیرهٔ پیوند یکتا هنوز 404 دارم؛ قدم بعدی چیست؟
ذخیره را تکرار نکنید. نوع وب‌سرور و مسیر نصب را مشخص کنید؛ سپس در Apache اجرای rewrite و در Nginx server block را بررسی کنید. پس از اصلاح مبدأ، کش نشانی‌های خراب را هم آزمایش کنید.
سرویس‌های مرتبط با این مطلب
برای بررسی راهکار مناسب، مشخصات و شرایط این خدمات را ببینید.
پرسش‌ها و دیدگاه‌های شما
سؤال یا تجربه مرتبط با این مطلب دارید؟ با ما و خوانندگان مجله آفاق هاست در میان بگذارید.