رفع خطای 404 Not Found در سرور + راهنمای علت‌یابی گام‌به‌گام

خطای 404 Not Found یکی از آشناترین کدهای وب است، ولی وقتی روی سایت خودتان ظاهر می‌شود، طعم کاملاً متفاوتی دارد: کاربر به صفحه‌ای می‌رسد که وجود ندارد، گوگل رتبه‌های ارزشمند را در طول چند هفته می‌سوزاند، و بازدیدکننده در چند ثانیه به سایت رقیب می‌رود. سال‌هاست روی سایت‌های تولیدی و پروژه‌های وردپرسی با این خطا کار می‌کنم و در تجربه‌ام، بیشترین آسیب 404 نه از خود خطا، بلکه از مدیریت دیرهنگام آن می‌آید.

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

معنای دقیق 404 در معماری وب

کد وضعیت 404 در پروتکل HTTP (Hypertext Transfer Protocol) به این معناست که سرور درخواست کاربر را دریافت کرده، مسیر درخواستی را فهمیده، ولی منبع مورد نظر را پیدا نکرده است. این تعریف ساده، در عمل پیچیده می‌شود؛ چون در معماری‌های مدرن، «فهمیدن» و «پیدا نکردن» می‌تواند در چند لایه اتفاق بیفتد: لایه‌ی وب‌سرور، لایه‌ی مسیریابی اپلیکیشن، لایه‌ی CDN یا لایه‌ی قواعد rewrite. توضیح تکمیلی این کد در ویکی‌پدیا موجود است، ولی جان ماجرا در همین پراکندگی است.

در پروژه‌های واقعی، تفکیک دو مفهوم بسیار مهم است: خطای 404 ناشی از لینک‌های شکسته در محتوای سایت، و خطای 404 ناشی از قواعد rewrite نادرست. دسته‌ی اول، مدیریت محتوایی می‌خواهد و دسته‌ی دوم، اصلاح پیکربندی. در تجربه‌ی من، مدیران سایت غالباً این دو را یکی می‌گیرند و نتیجه این می‌شود که ماه‌ها وقت صرف ریدایرکت لینک‌های شکسته می‌کنند، در حالی که ریشه‌ی اصلی، یک قاعده‌ی rewrite معیوب است که هر روز لینک شکسته‌ی جدید می‌سازد.

نکته‌ی دیگری که در تجربه‌ی چندساله‌ام بارها دیده‌ام این است که خطای 404 گاهی عمدی و مفید است. حذف دائمی یک محصول، ادغام دو مقاله، یا حذف یک دسته‌بندی، همه می‌توانند به 404 منجر شوند و این رفتار درست است. مسئله زمانی شروع می‌شود که این 404 بدون ریدایرکت باقی بماند و گوگل را به تشخیص «منبع از دست رفته» برساند. مباحث پایه‌ای مرتبط با معماری وب در سرور چیست و چگونه کار می‌کند باز شده است.

خطای 404 پیام مرگ یک صفحه نیست؛ پیام این است که آدرس درخواستی در آن لحظه پاسخ نداده. تفاوت این دو نگاه، تفاوت میان حذف و بازیابی است.

تفاوت 404 با 403، 410 و 500

چهار کد خطای رایج که مدیران سایت با هم اشتباه می‌گیرند، معنای فنی متفاوتی دارند و مسیر عیب‌یابی هر یک جداست:

کد	معنا	وضعیت منبع	نشانه‌ی تشخیص
403	Forbidden	منبع وجود دارد ولی دسترسی ممنوع	مسدودسازی توسط سرور یا فایروال
404	Not Found	منبع پیدا نمی‌شود	آدرس درخواستی پاسخ ندارد
410	Gone	منبع برای همیشه حذف شده	حذف عمدی و دائمی
500	Internal Server Error	منبع وجود دارد ولی سرور خطا داد	خطای کشنده در کد

تفکیک 404 از 410 در سئو اهمیت زیادی دارد: گوگل، 404 را به‌عنوان وضعیت موقت در نظر می‌گیرد و به‌سرعت صفحه را از ایندکس خارج نمی‌کند، ولی 410 را به‌عنوان حذف دائمی تلقی می‌کند. اگر قصد حذف همیشگی یک صفحه را دارید، 410 دقیق‌تر است؛ اگر فقط می‌خواهید مسیر عوض شود، ریدایرکت 301 بهترین انتخاب است. مسیر دقیق عیب‌یابی 500 در رفع خطای 500 Internal Server Error در وردپرس و عیب‌یابی 403 در رفع خطای 403 Forbidden در سرور باز شده است.

ده ریشه‌ی شایع خطای 404

در عیب‌یابی خطای 404 روی سایت‌های تولیدی، این ده ریشه بیش از بقیه تکرار می‌شوند. تشخیص دقیق، نیمی از راه‌حل است:

ریشه‌ی اول: تغییر ساختار پیوندهای یکتا

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

ریشه‌ی دوم: حذف یا تغییر نام نوشته‌ها و برگه‌ها

وقتی یک نوشته حذف می‌شود یا نامک (slug) آن تغییر می‌کند، آدرس قدیمی 404 می‌دهد. در سایت‌های بزرگ، این تغییر نام‌ها معمولاً در فهرست‌های طولانی رخ می‌دهد و اگر ریدایرکت خودکار تنظیم نشده باشد، لینک‌های درون‌سایتی و بک‌لینک‌های بیرونی از کار می‌افتند.

ریشه‌ی سوم: قواعد rewrite معیوب

در وردپرس، تمام درخواست‌ها از طریق قواعد rewrite در .htaccess به فایل index.php هدایت می‌شوند. اگر این قواعد ناقص یا تغییر یافته باشند، حتی صفحات موجود هم 404 می‌دهند. این سناریو معمولاً بعد از تغییر سرور یا نصب افزونه‌ای که به .htaccess دست می‌زند رخ می‌دهد.

ریشه‌ی چهارم: حذف دسته‌بندی یا تاکسونومی

اگر یک دسته‌بندی یا تاکسونومی سفارشی حذف شود، تمام صفحات آرشیو آن 404 می‌دهند. این لینک‌ها معمولاً در سایت‌های بزرگ زیاد هستند و اگر ریدایرکت نشوند، حجم زیادی از ترافیک ارگانیک از دست می‌رود.

ریشه‌ی پنجم: مشکل در فایل‌های رسانه

اگر فایل‌های رسانه (تصاویر، ویدئو، PDF) از کتابخانه حذف شوند ولی URL آن‌ها در محتوا باقی بماند، درخواست به آن فایل‌ها 404 می‌گیرد. این خطاها در سئوی تصویر اهمیت زیادی دارند و اغلب نادیده گرفته می‌شوند.

ریشه‌ی ششم: لینک‌های شکسته در محتوای قدیمی

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

ریشه‌ی هفتم: مهاجرت ناقص سرور

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

ریشه‌ی هشتم: تداخل افزونه‌ی سئو با htaccess

افزونه‌های سئو معمولاً برای مدیریت ریدایرکت‌ها، به .htaccess یا به سطح داخلی وردپرس دست می‌زنند. اگر این قواعد با قواعد وردپرس تضاد داشته باشند، بخشی از صفحات 404 می‌دهند. این سناریو در سایت‌هایی که چند افزونه‌ی سئو همزمان نصب دارند، شایع‌تر است.

ریشه‌ی نهم: تغییر دامنه بدون ریدایرکت

اگر دامنه‌ی سایت تغییر کند ولی ریدایرکت 301 از دامنه‌ی قدیمی به جدید تنظیم نشود، تمام لینک‌های بیرونی به دامنه‌ی قدیمی 404 می‌دهند. این سناریو در سایت‌هایی که دامنه را بدون برنامه‌ریزی عوض می‌کنند، بسیار پرهزینه است.

ریشه‌ی دهم: خطا در کد سفارشی یا قالب

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

پروتکل واکنش سریع به 404

اگر همین حالا روی سایت شما 404 دیده می‌شود و می‌خواهید آسیب سئویی را کاهش دهید، این پنج حرکت را به همین ترتیب اجرا کنید:

تعیین دامنه‌ی خطا: سریع تست کنید که آیا 404 در همه‌ی صفحات است یا فقط بعضی. اگر همه‌ی سایت 404 می‌دهد، ریشه در htaccess یا rewrite است. اگر فقط بعضی صفحات، به سراغ محتوا و ریدایرکت‌ها بروید.
بررسی پیوندهای یکتا: از مسیر پیشخوان وردپرس، تنظیمات پیوندهای یکتا را باز کنید و بدون تغییر، روی ذخیره بزنید. این کار قواعد rewrite را بازسازی می‌کند و بسیاری از 404ها را برطرف می‌کند.
بازسازی htaccess: اگر ریشه در htaccess است، فایل را با محتوای پیش‌فرض وردپرس بازسازی کنید.
تست با قالب پیش‌فرض: اگر ریشه در قالب است، قالب را موقتاً به یک قالب پیش‌فرض تغییر دهید و سایت را تست کنید.
ریدایرکت لینک‌های مهم: سریع لینک‌های پرترافیک را شناسایی و ریدایرکت 301 بزنید. این کار فوری، بخش بزرگی از آسیب سئویی را کاهش می‌دهد.

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

خواندن لاگ‌ها برای یافتن لینک‌های شکسته

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

الگوی 404 در لاگ آپاچی

در فایل access.log آپاچی، هر خط 404 به شکل زیر دیده می‌شود:

192.0.2.1 - - [10/Oct/2026:12:34:56 +0330] "GET /old-page-slug/ HTTP/1.1" 404 1234 "-" "Mozilla/5.0 ..."

بخش GET /old-page-slug/ مسیر درخواستی و بخش 404 کد وضعیت است. با اجرای دستور زیر می‌توانید پرتکرارترین مسیرهای 404 را ببینید:

awk '$9 == 404 {print $7}' /var/log/apache2/access.log | sort | uniq -c | sort -rn | head -30

این دستور، سی مسیر پرتکرار 404 را نشان می‌دهد. تحلیل این لیست، اولین گام در مدیریت 404 است.

الگوی 404 در لاگ Nginx

در فایل access.log Nginx، همان اطلاعات با ساختار مشابه دیده می‌شود. برای استخراج پرتکرارترین مسیرهای 404:

awk '$9 == 404 {print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -30

تحلیل منبع 404

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

پیوندهای یکتا و قواعد rewrite

در وردپرس، ساختار پیوندهای یکتا (Permalink) تعیین می‌کند که هر نوشته، برگه یا محصول با چه آدرسی نمایش داده شود. اگر این ساختار تغییر کند، تمام لینک‌های قدیمی از کار می‌افتند و 404 می‌دهند. سه نکته‌ی مهم در این زمینه:

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

ساختار پیشنهادی وردپرس که تعادل خوبی بین خوانایی و سئو دارد:

/%postname%/

یا برای تفکیک نوشته از برگه و دسته:

/blog/%postname%/

توصیه می‌کنم این ساختار را از همان ابتدای راه‌اندازی سایت انتخاب کنید. اگر بعداً تغییر دهید، باید ریدایرکت‌های جامع تنظیم کنید. مباحث مرتبط با راه‌اندازی در راه‌اندازی سایت وردپرسی باز شده است.

بازسازی قواعد rewrite

گاهی ریشه‌ی 404 در قواعد rewrite است که در جدول wp_options ذخیره شده‌اند. برای بازسازی این قواعد، از مسیر پیشخوان وردپرس، بخش تنظیمات > پیوندهای یکتا را باز کنید و بدون تغییر، روی ذخیره تغییرات بزنید. این کار به‌صورت خودکار قواعد rewrite را بازسازی می‌کند.

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

DELETE FROM wp_options WHERE option_name = 'rewrite_rules';

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

htaccess و پیکربندی وب‌سرور

فایل .htaccess در آپاچی، قلب مسیریابی وردپرس است. اگر این فایل ناقص یا تغییر یافته باشد، 404 می‌تواند حتی برای صفحات موجود ظاهر شود.

محتوای استاندارد htaccess وردپرس

محتوای پیش‌فرض وردپرس در .htaccess به این شکل است:

# BEGIN WordPress
<IfModule mod_rewrite.c>
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]
</IfModule>
# END WordPress

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

بازسازی htaccess در Nginx

Nginx از .htaccess پشتیبانی نمی‌کند و قواعد مسیریابی مستقیماً در فایل پیکربندی تعریف می‌شوند. الگوی استاندارد برای وردپرس:

location / {
    try_files $uri $uri/ /index.php?$args;
}

این قاعده به Nginx می‌گوید که اگر فایل یا پوشه‌ی درخواستی وجود نداشت، درخواست را به index.php وردپرس هدایت کند. اگر این قاعده ناقص باشد، تمام صفحات غیر از صفحه‌ی اصلی 404 می‌دهند.

بررسی مجوز فایل htaccess

فایل .htaccess باید مجوز 644 داشته باشد. اگر مجوز بالاتر (مثلاً 666) باشد، ممکن است افزونه‌ها بدون اطلاع شما آن را ویرایش کنند. اگر مجوز کمتر (مثلاً 600) باشد، وب‌سرور نمی‌تواند آن را بخواند و قواعد اعمال نمی‌شوند.

قالب، افزونه و کد سفارشی

بعد از اطمینان از سلامت مسیریابی سرور، نوبت به لایه‌ی اپلیکیشن می‌رسد. سه سناریوی رایج:

تداخل قالب با مسیریابی وردپرس

بعضی قالب‌ها، منطق مسیریابی سفارشی دارند و ممکن است درخواست‌های خاصی را به‌اشتباه به 404 هدایت کنند. این سناریو در قالب‌هایی که از سیستم‌های مسیریابی جداگانه استفاده می‌کنند، شایع‌تر است. تست سریع: قالب را به Twenty Twenty-Four تغییر دهید. اگر 404 برطرف شد، مقصر قالب است.

افزونه‌های تغییردهنده‌ی پیوندهای یکتا

بعضی افزونه‌ها، ساختار پیوندهای یکتا را برای انواع خاصی از محتوا تغییر می‌دهند. اگر این تغییرات با ساختار وردپرس ناسازگار باشد، 404 ظاهر می‌شود. این سناریو در فروشگاه‌های ووکامرس که از افزونه‌ی سفارشی‌سازی مسیر محصول استفاده می‌کنند، شایع‌تر است. مباحث مرتبط با این حوزه در سفارشی‌سازی صفحه محصول در ووکامرس باز شده است.

تداخل افزونه‌های سئو

افزونه‌های سئو مثل Yoast یا Rank Math، قواعد rewrite مخصوص خود را برای sitemap و مسیرهای دیگر تعریف می‌کنند. اگر دو افزونه‌ی سئو همزمان نصب باشد، این قواعد با هم تضاد پیدا می‌کنند و بعضی صفحات 404 می‌دهند. راه‌حل: فقط یک افزونه‌ی سئو فعال نگه دارید. مباحث مرتبط در افزونه‌های سئو وردپرس پوشش داده شده است.

کد سفارشی در functions.php

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

ریدایرکت 301 به‌عنوان راه‌حل ریشه‌ای

ریدایرکت 301 (Permanent Redirect) مؤثرترین راه‌حل برای مدیریت 404های ناشی از جابه‌جایی محتواست. این کد به گوگل می‌گوید که منبع به‌صورت دائمی جابه‌جا شده و باید اعتبار به مسیر جدید منتقل شود.

ریدایرکت در وردپرس

سه روش برای ریدایرکت در وردپرس وجود دارد:

افزونه‌های ریدایرکت: افزونه‌هایی مثل Redirection یا Safe Redirect Manager اجازه می‌دهند از پیشخوان وردپرس، قواعد ریدایرکت را تعریف کنید. این روش برای کاربران غیرفنی ساده‌تر است.
قواعد در htaccess: برای ریدایرکت‌های جمعی یا الگو-محور، می‌توانید قواعد را مستقیماً در .htaccess بنویسید. مثال:

Redirect 301 /old-page/ /new-page/
RedirectMatch 301 ^/blog/(.*)$ /articles/$1

ریدایرکت در سطح سرور: در Nginx، قواعد ریدایرکت در فایل پیکربندی تعریف می‌شوند. مثال:

location = /old-page/ {
    return 301 /new-page/;
}

ریدایرکت دامنه

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

# Apache
RewriteEngine On
RewriteCond %{HTTP_HOST} ^old-domain\.com [NC]
RewriteRule ^(.*)$ https://new-domain.com/$1 [L,R=301]

ریدایرکت‌های زنجیره‌ای را حذف کنید

یک اشتباه رایج، ایجاد زنجیره‌ی ریدایرکت است: مسیر A به B، B به C و C به D. این زنجیره‌ها سرعت را کاهش می‌دهند و گاهی باعث 404 می‌شوند. توصیه: هر مسیر را مستقیم به مقصد نهایی ریدایرکت کنید.

ابزارها و پایش مستمر لینک‌های شکسته

مدیریت 404 یک پروژه‌ی یک‌باره نیست؛ یک فرآیند مستمر است. ابزارها و روش‌های پایش:

Google Search Console

در بخش Coverage یا Pages، صفحاتی که 404 می‌دهند گزارش می‌شوند. این گزارش، دقیق‌ترین منبع برای یافتن 404هایی است که گوگل دیده. توصیه: هفته‌ای یک‌بار این گزارش را بررسی کنید.

ابزارهای تحلیل لاگ

ابزارهایی مثل GoAccess یا AWStats، لاگ وب‌سرور را تحلیل می‌کنند و گزارش 404ها را نشان می‌دهند. این ابزارها برای سایت‌های بزرگ که حجم بالایی از درخواست دارند، کاراتر هستند.

افزونه‌های پایش لینک شکسته

افزونه‌هایی مثل Broken Link Checker، لینک‌های سایت را به‌صورت دوره‌ای بررسی می‌کنند و لینک‌های شکسته را گزارش می‌دهند. این ابزار برای سایت‌های متوسط و کوچک، ساده‌ترین راه است. مباحث مرتبط با پایش سایت در بررسی خطاهای سرور در لاگ‌ها باز شده است.

پایش خارجی

سرویس‌هایی مثل Uptime Robot یا Pingdom، می‌توانند چند صفحه‌ی کلیدی سایت را پایش کنند و در صورت 404، هشدار بدهند. این سطح پایش، برای صفحات پرترافیک توصیه می‌شود.

تأثیر 404 بر سئو و روش کاهش آسیب

خطای 404، اگر به‌درستی مدیریت نشود، می‌تواند آسیب جدی به سئو وارد کند. سه سطح آسیب:

آسیب سطح اول: از دست دادن اعتبار بک‌لینک‌ها

اگر یک صفحه‌ی پراعتبار حذف شود و لینک‌های بیرونی به آن 404 بدهند، اعتبار آن بک‌لینک‌ها از دست می‌رود. راه‌حل: ریدایرکت 301 به صفحه‌ی مرتبط یا صفحه‌ی اصلی همان موضوع.

آسیب سطح دوم: افت نرخ کلیک ارگانیک

اگر صفحات پرترافیک حذف شوند، ترافیک ارگانیک آن‌ها به‌سرعت افت می‌کند. راه‌حل: پیش از حذف هر صفحه، محتوایش را در صفحه‌ی مرتبط ادغام کنید و ریدایرکت بزنید.

آسیب سطح سوم: تخریب تجربه‌ی کاربر

کاربری که با 404 رو‌به‌رو می‌شود، معمولاً در چند ثانیه سایت را ترک می‌کند. راه‌حل: طراحی صفحه‌ی 404 سفارشی که کاربر را به مسیرهای مرتبط هدایت کند. مباحث مرتبط با تجربه‌ی کاربر در تجربه کاربری چیست باز شده است.

بازگردانی مسیرها و اولویت‌بندی

بعد از یافتن 404های مهم، نوبت به بازگردانی و ریدایرکت می‌رسد. ترتیب اولویت‌بندی من در پروژه‌های واقعی:

اولویت اول: صفحات پرترافیک. ابتدا مسیرهایی را ریدایرکت کنید که در Google Search Console ترافیک دارند.
اولویت دوم: صفحات با بک‌لینک. مسیرهایی که از سایت‌های بیرونی به آن‌ها لینک داده شده، در اولویت بعدی هستند.
اولویت سوم: صفحات پرارجاع درون‌سایتی. مسیرهایی که در محتوای فعلی به آن‌ها لینک داده شده، در اولویت سوم قرار می‌گیرند.
اولویت چهارم: مسیرهای باقی‌مانده. اگر مسیرهای دیگر ترافیک ندارند و بک‌لینکی هم ندارند، می‌توانید آن‌ها را به‌عنوان 404 باقی بگذارید یا به 410 تغییر دهید.

پیشگیری و عادت‌های امن

بعد از رفع، مهم‌تر از رفع، پیشگیری است. پنج عادت که در پروژه‌هایم همیشه رعایت می‌کنم:

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

پرسش‌های پرتکرار درباره خطای 404

خطای 404 روی سئو چه تأثیری دارد؟

گوگل 404 را به‌عنوان وضعیت موقت تلقی می‌کند و بلافاصله صفحه را از ایندکس خارج نمی‌کند. اما اگر این وضعیت ماه‌ها ادامه یابد، گوگل صفحه را از ایندکس حذف می‌کند و اعتبار بک‌لینک‌ها از دست می‌رود. راه‌حل: صفحات پرترافیک را سریعاً ریدایرکت کنید.

تفاوت 404 و 410 در وردپرس چیست؟

404 به‌معنای «پیدا نشد» است و 410 به‌معنای «برای همیشه حذف شده». در سئو، 410 سیگنال قوی‌تری برای حذف است و گوگل سریع‌تر صفحه را از ایندکس خارج می‌کند. برای حذف دائمی از 410 استفاده کنید، برای جابه‌جایی از 301.

آیا 404 می‌تواند ناشی از هک شدن سایت باشد؟

در موارد نادر بله. اگر هکر فایل‌های مسیریابی را تغییر دهد یا محتوای سایت را دست‌کاری کند، ممکن است 404 ظاهر شود. برای اطمینان، روش تشخیص هک شدن سایت را بررسی کنید.

چطور بفهمم 404 از سرور است یا از وردپرس؟

سریع‌ترین تست، بررسی نوع پاسخ در سربرگ HTTP است. اگر پاسخ از سرور است، معمولاً صفحه‌ی 404 پیش‌فرض وب‌سرور نمایش داده می‌شود. اگر از وردپرس است، معمولاً قالب سایت در آن صفحه اعمال شده است. بررسی دقیق‌تر با ابزارهایی مثل curl یا مرورگر امکان‌پذیر است.

آیا 404 روی رتبه‌ی کلی سایت تأثیر می‌گذارد؟

تعداد محدود 404 در سایت طبیعی است و تأثیر منفی جدی ندارد. اما اگر تعداد 404 زیاد باشد یا صفحات پرترافیک 404 بدهند، می‌تواند اعتماد گوگل به سایت را کاهش دهد و روی رتبه‌ی کلی اثر منفی بگذارد.

چطور لینک‌های شکسته‌ی سایت را پیدا کنم؟

سه روش: اول، گزارش Coverage گوگل سرچ کنسول. دوم، ابزارهای تحلیل لاگ مثل GoAccess. سوم، افزونه‌های پایش لینک شکسته مثل Broken Link Checker. توصیه: ترکیبی از هر سه را استفاده کنید.

آیا باید همه‌ی لینک‌های 404 را ریدایرکت کنم؟

خیر. فقط لینک‌هایی که ترافیک، بک‌لینک یا ارجاع درون‌سایتی دارند باید ریدایرکت شوند. لینک‌های بی‌اهمیت را می‌توانید به‌عنوان 404 باقی بگذارید یا به 410 تغییر دهید.

تأثیر ریدایرکت زنجیره‌ای چیست؟

ریدایرکت زنجیره‌ای (مسیر A به B، B به C) باعث کاهش سرعت و کاهش اعتبار منتقل‌شده می‌شود. توصیه: همیشه هر مسیر را مستقیم به مقصد نهایی ریدایرکت کنید. مباحث مرتبط در افزونه‌های ریدایرکت وردپرس پوشش داده شده است.

آیا صفحه‌ی 404 سفارشی بر سئو تأثیر دارد؟

صفحه‌ی 404 سفارشی، تأثیر مستقیم روی سئو ندارد ولی تجربه‌ی کاربر را بهبود می‌دهد. کاربری که در صفحه‌ی 404 به مسیرهای مرتبط هدایت شود، احتمال ماندنش بالاتر است. این بهبود تجربه، به‌طور غیرمستقیم روی سئو اثر مثبت دارد.

چطور بعد از تغییر دامنه از 404 جلوگیری کنم؟

قبل از تغییر دامنه، نقشه‌ی مسیرهای قدیمی و جدید را تهیه کنید و ریدایرکت 301 را در سرور جدید تنظیم کنید. سپس به‌تدریج فایل .htaccess یا پیکربندی Nginx را با ریدایرکت‌های دقیق تکمیل کنید. تست نهایی با curl روی چند مسیر نمونه انجام دهید.

نکته‌های میدانی از مدیریت بحران 404

در پایان این مقاله، چند نکته‌ای را می‌گویم که در مستندات رسمی کم‌تر به آن‌ها اشاره می‌شود ولی در پروژه‌های واقعی بارها به کارم آمده:

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

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

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

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

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