راهنمای جامع خطاهای سایت؛ معنی و رفع خطای ۴۰۴، ۵۰۰، ۵۰۲ و ۵۰۳ با کمک هوش مصنوعی

خطاهای سایت معمولاً در بدترین لحظه ظاهر می‌شوند. وارد سایت می‌شوید و به‌جای صفحهٔ موردنظر، پیامی مثل «500 Internal Server Error» یا «503 Service Unavailable» می‌بینید. گاهی هم سایت باز می‌شود، اما هنگام ورود، پرداخت یا ارسال فرم خطا می‌دهد.

این پیام‌ها بی‌معنی نیستند. هرکدام سرنخی دربارهٔ محل مشکل می‌دهد. بعضی به آدرس یا اطلاعات ارسالی مربوط‌اند. بعضی از تنظیمات دسترسی می‌آیند و بعضی می‌گویند سرور یا سرویسی پشت آن درست کار نمی‌کند.

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

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

کد وضعیت HTTP چیست و چه ربطی به خطاهای سایت دارد؟

وقتی صفحه‌ای را باز می‌کنید، مرورگر درخواستی به سرور سایت می‌فرستد. سرور در پاسخ، علاوه بر محتوای صفحه، یک عدد سه‌رقمی به نام «کد وضعیت HTTP» هم برمی‌گرداند. رقم اول این عدد، خانوادهٔ پاسخ را مشخص می‌کند.

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

برای مثال، 200 نشانهٔ موفقیت است و 301 انتقال دائمی به آدرس دیگری را نشان می‌دهد. در مقابل، 404 می‌گوید منبع پیدا نشده و 500 از یک مشکل داخلی خبر می‌دهد. فهرست کامل را می‌توانید در مرجع کدهای وضعیت HTTP در MDN ببینید.

البته عبارت «خطای سمت کاربر» برای خانوادهٔ 4xx به این معنی نیست که حتماً بازدیدکننده اشتباه کرده است. یک لینک خراب، تنظیم نادرست دسترسی یا باگ در کد سایت هم می‌تواند چنین پاسخی بسازد.

جدول سریع خطاهای پرکاربرد سایت

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

ستون آخر فقط اولین جایی است که باید نگاه کنید؛ علت نهایی ممکن است جای دیگری باشد.

خطا در کدام لایهٔ سایت رخ می‌دهد؟

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

هر لایه می‌تواند خطای خودش را تولید کند. به همین دلیل، دانستن اینکه کدام لایه پاسخ را ساخته، نیمی از عیب‌یابی است. برای نمونه، 502 و 504 معمولاً از واسطه‌ای می‌آیند که منتظر لایهٔ بعدی مانده است. در مقابل، 500 اغلب از خود برنامه صادر می‌شود.

پس وقتی خطایی می‌بینید، اول بپرسید «چه کسی این پاسخ را داده است؟». صفحهٔ خطای CDN، صفحهٔ پیش‌فرض وب‌سرور و صفحهٔ خطای طراحی‌شدهٔ سایت ظاهر متفاوتی دارند و همین تفاوت سرنخ خوبی است.

خطای سایت را چطور از هوش مصنوعی بپرسیم؟

ابزارهایی مثل ChatGPT و Claude در عیب‌یابی خطاهای سایت کمک خوبی هستند؛ به شرط اینکه اطلاعات کافی بگیرند. سؤالی مثل «سایتم خطای 500 می‌دهد، چه کنم؟» فقط یک فهرست کلی از علت‌ها برمی‌گرداند.

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

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

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

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

خطاهای سمت سرور (5xx)؛ وقتی سرور نمی‌تواند پاسخ دهد

کدهای 5xx یعنی درخواست احتمالاً درست بوده، اما سرور یا یکی از سرویس‌های پشت آن نتوانسته کار را تمام کند. این خطاها معمولاً از دست بازدیدکننده خارج‌اند و رفعشان کار مدیر سایت یا تیم فنی است.

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

چهار خطای مهم این گروه 500، 502، 503 و 504 هستند. تصویر زیر معنی و نقطهٔ شروع بررسی هرکدام را کنار هم نشان می‌دهد.

خطای 500؛ خطای داخلی سرور

پیام 500 Internal Server Error زمانی نمایش داده می‌شود که سرور با وضعیتی غیرمنتظره روبه‌رو شده و نمی‌تواند درخواست را کامل کند. این کد عمومی است و به‌تنهایی نمی‌گوید کدام بخش خراب شده است. جزئیات بیشتر در توضیح خطای 500 در MDN آمده است.

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

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

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

برای پرسیدن این خطا از هوش مصنوعی، این پرامپت را کپی کنید:

سایت من در آدرس [آدرس صفحه] خطای 500 Internal Server Error می‌دهد.
محیط سایت: [مثلاً وردپرس یا لاراول، نوع هاست، نسخهٔ PHP، CDN].
خطا از [زمان شروع] شروع شده و [برای همه / فقط بعضی صفحه‌ها] رخ می‌دهد.
تغییرات اخیر: [به‌روزرسانی افزونه، انتشار کد، تغییر تنظیمات].
این چند خط از گزارش خطا مربوط به همان زمان است:
[خطوط گزارش، بدون رمز و اطلاعات شخصی]
سه علت محتمل را به ترتیب احتمال بنویس و برای هرکدام بگو چه شاهدی آن را تأیید یا رد می‌کند.
سپس قدم‌های بررسی کم‌خطر را پیشنهاد بده. علت قطعی اعلام نکن و تغییری روی سایت زنده پیشنهاد نده که قابل برگشت نباشد.

خطای 502؛ پاسخ نامعتبر از سرور بالادستی

بسیاری از سایت‌ها پشت یک واسطه مانند پراکسی، متعادل‌کنندهٔ بار یا CDN قرار دارند. خطای 502 Bad Gateway یعنی همین واسطه از سرور بعدی پاسخ معتبری دریافت نکرده است. توضیح رسمی را در صفحهٔ خطای 502 در MDN ببینید.

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

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

این پرامپت به هوش مصنوعی کمک می‌کند مسیر ارتباط را قدم‌به‌قدم بررسی کند:

سایت من خطای 502 Bad Gateway می‌دهد.
مسیر درخواست: [مثلاً CDN ← Nginx ← PHP-FPM ← برنامه].
صفحهٔ خطا از طرف [CDN / وب‌سرور / نامشخص] نمایش داده می‌شود.
خطا از [زمان] شروع شده و تغییر اخیر ما [شرح تغییر] بوده است.
گزارش وب‌سرور در همان زمان: [خطوط گزارش].
مشخص کن کدام اتصال در این مسیر احتمالاً شکست خورده است.
برای هر حلقهٔ مسیر یک بررسی ساده بده تا بفهمم سرویس فعال است و پاسخ معتبر می‌دهد.

خطای 503؛ سرویس موقتاً در دسترس نیست

پیام 503 Service Unavailable نشان می‌دهد سرویس در این لحظه آمادهٔ پردازش درخواست نیست. فشار زیاد و حالت نگهداری (Maintenance) دو علت شناخته‌شدهٔ آن هستند. سرور می‌تواند با هدر Retry-After زمان پیشنهادی تلاش دوباره را هم اعلام کند؛ جزئیات در توضیح خطای 503 در MDN آمده است.

برای نمونه، در شروع یک فروش ویژه ممکن است تعداد درخواست‌ها از ظرفیت سایت بیشتر شود. روی هاست اشتراکی هم رسیدن به سقف منابع حساب، مثل تعداد پردازه‌های هم‌زمان، معمولاً به همین خطا ختم می‌شود.

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

برای بررسی این خطا با هوش مصنوعی، از این پرامپت استفاده کنید:

سایت من گاهی خطای 503 Service Unavailable می‌دهد.
نوع میزبانی: [هاست اشتراکی / VPS / سرور ابری] با این محدودیت‌ها: [CPU، رم، پردازهٔ هم‌زمان].
الگوی خطا: [همیشگی / در ساعت‌های پربازدید / بعد از یک عملیات خاص].
حالت نگهداری سایت [فعال / غیرفعال] است و تغییر اخیر ما [شرح] بوده است.
آمار منابع یا گزارش سرور در زمان خطا: [داده‌ها].
بگو این الگو بیشتر به کمبود ظرفیت، مصرف غیرعادی منابع یا حالت نگهداری شبیه است.
قبل از پیشنهاد ارتقای سرور، راه‌های پیدا کردن پردازش پرمصرف را توضیح بده.

خطای 504؛ پاسخ سرور بعدی دیر رسیده است

خطای 504 Gateway Timeout یعنی یک واسطه برای کامل کردن درخواست منتظر سرور دیگری بوده، اما پاسخ در زمان مجاز نرسیده است. توضیح کامل آن در صفحهٔ خطای 504 در MDN هست.

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

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

این پرامپت را برای پیدا کردن مرحلهٔ کند به هوش مصنوعی بدهید:

صفحهٔ [آدرس یا نام عملیات] در سایت من بعد از حدود [چند] ثانیه خطای 504 Gateway Timeout می‌دهد.
مسیر درخواست: [مثلاً CDN ← وب‌سرور ← برنامه ← پایگاه داده / API خارجی].
این عملیات [چه کاری انجام می‌دهد، مثلاً ساخت گزارش یا ارسال ایمیل].
زمان‌های ثبت‌شده در گزارش یا ابزار پایش: [داده‌ها].
کمکم کن بفهمم زمان در کدام مرحله مصرف می‌شود و چطور آن را اندازه بگیرم.
بگو این عملیات برای پردازش پس‌زمینه مناسب است یا باید خود پرس‌وجو را سریع‌تر کرد.

تفاوت 500، 502، 503 و 504 چیست؟

این چهار خطا شبیه هم به نظر می‌رسند، اما هرکدام سؤال تشخیصی متفاوتی دارد. جدول زیر همین سؤال‌ها را کنار هم گذاشته است:

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

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

بیشتر بخوانید: پرامپت خوب چه ویژگی‌هایی دارد؟ پنج اصل ساده

خطاهای سمت درخواست (4xx)؛ وقتی سرور درخواست را نمی‌پذیرد

کدهای 4xx یعنی سرور درخواست را دریافت کرده، اما به‌دلیل مشکلی در خود درخواست، دسترسی یا نشانی آن را انجام نمی‌دهد. این گروه پرتعدادترین خطاهای سایت را در بر می‌گیرد و معروف‌ترین آن‌ها 404 است.

خبر خوب این است که بسیاری از خطاهای 4xx با بررسی آدرس، ورود دوباره یا اصلاح داده حل می‌شوند. البته اگر همین خطاها برای همهٔ کاربران تکرار شوند، معمولاً ایراد از تنظیمات یا کد سایت است.

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

خطای 400؛ درخواست نامعتبر

پیام 400 Bad Request یعنی سرور درخواست را به‌دلیل مشکلی که در آن تشخیص داده پردازش نمی‌کند. ساختار نامعتبر درخواست علت اصلی آن است؛ توضیح رسمی در صفحهٔ خطای 400 در MDN آمده است.

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

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

برای بررسی خطای 400 با هوش مصنوعی، درخواست خام را هم به پرامپت اضافه کنید:

درخواست زیر به سایت یا API من پاسخ 400 Bad Request می‌گیرد:
روش و آدرس: [مثلاً POST /api/orders]
هدرها: [هدرها، بدون توکن]
بدنهٔ درخواست: [بدنه]
متن پاسخ سرور: [پاسخ]
خطا [همیشه / فقط در یک مرورگر / فقط از طریق CDN] رخ می‌دهد.
بگو کدام بخش درخواست احتمالاً نامعتبر است و چطور آن را آزمایش کنم.

خطای 401؛ نیاز به احراز هویت معتبر

پیام 401 Unauthorized معمولاً یعنی درخواست اطلاعات ورود معتبر ندارد. ممکن است اطلاعات ورود ارسال نشده باشد یا اعتبار آن تمام شده باشد. نمونهٔ رایج آن منقضی‌شدن توکن دسترسی یک برنامه است. جزئیات را در صفحهٔ خطای 401 در MDN ببینید.

برای کاربر، ورود دوباره به حساب معمولاً اولین قدم است. اگر چند حساب دارد، باید مطمئن شود با حساب درست وارد شده است. برای توسعه‌دهنده، بررسی هدر Authorization، اعتبار توکن، فرایند تمدید آن و ارسال درست کوکی نشست ضروری است.

تفاوت اصلی 401 با 403 این است که در 401 سرور هنوز نمی‌داند شما چه کسی هستید. در مقابل، در 403 سرور شما را شناخته یا درخواست را فهمیده، اما اجازهٔ دسترسی نمی‌دهد.

این پرامپت برای پیدا کردن ایراد احراز هویت مناسب است:

درخواست من به [آدرس یا API] خطای 401 Unauthorized می‌گیرد.
روش احراز هویت: [کوکی نشست / توکن Bearer / کلید API / OAuth].
ورود [همیشه / بعد از مدتی / فقط در یک دستگاه] با شکست روبه‌رو می‌شود.
هدرهای پاسخ سرور: [هدرها، بدون مقدار توکن].
کمکم کن بفهمم مشکل از ارسال‌نشدن اطلاعات ورود است، از انقضای آن یا از تنظیمات سرور.
یک چک‌لیست کوتاه برای بررسی سمت کاربر و سمت سرور بده.

خطای 403؛ دسترسی ممنوع

پیام 403 Forbidden یعنی سرور درخواست را فهمیده، اما انجامش نمی‌دهد. برخلاف 401، ورود دوباره لزوماً این مشکل را حل نمی‌کند. توضیح رسمی آن در صفحهٔ خطای 403 در MDN آمده است. علت‌های رایج این‌ها هستند:

• نبود مجوز کافی: حساب کاربری نقش یا دسترسی لازم را ندارد.
• قانون امنیتی: فایروال، افزونهٔ امنیتی یا CDN درخواست را مسدود کرده است.
• محدودیت شبکه: دسترسی بر اساس کشور یا نشانی IP محدود شده است.
• مجوز فایل: سطح دسترسی یا مالکیت فایل‌ها روی سرور نادرست است.
• فهرست پوشه: نمایش محتوای یک پوشه بدون فایل index ممنوع است.

کاربر باید سطح دسترسی حساب خود را بررسی کند و در صورت نیاز با پشتیبانی تماس بگیرد. مدیر سایت هم باید مشخص کند کدام لایه دسترسی را رد کرده است: برنامه، وب‌سرور، افزونهٔ امنیتی یا CDN.

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

برای پیدا کردن لایه‌ای که دسترسی را رد کرده، این پرامپت را بپرسید:

صفحهٔ [آدرس] در سایت من خطای 403 Forbidden می‌دهد.
این خطا [برای همه / فقط برای کاربران خاص / فقط از بعضی کشورها یا IPها] رخ می‌دهد.
لایه‌های امنیتی سایت: [مثلاً CDN، فایروال هاست، افزونهٔ امنیتی، قوانین htaccess].
ظاهر صفحهٔ خطا: [صفحهٔ CDN / صفحهٔ پیش‌فرض وب‌سرور / صفحهٔ سایت].
تغییر اخیر: [شرح].
کمکم کن بفهمم کدام لایه دسترسی را رد کرده و در گزارش کدام‌یک باید دنبال شاهد بگردم.
راه‌حلی مثل مجوز 777 یا خاموش کردن کامل فایروال پیشنهاد نده.

خطای 404؛ صفحه یا فایل پیدا نشد

پیام 404 Not Found یعنی سرور منبع موردنظر را پیدا نکرده است. این کد به‌تنهایی نمی‌گوید نبودن منبع دائمی است یا موقت. توضیح کامل در صفحهٔ خطای 404 در MDN آمده است.

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

مدیر سایت ابتدا باید وجود صفحه و درستی مسیر آن را بررسی کند. اگر محتوا جابه‌جا شده، ریدایرکت 301 به آدرس جدید بهترین راه است. همچنین یک صفحهٔ 404 خوب توضیح روشن، جست‌وجو و لینک‌های مفید دارد، اما پاسخ HTTP آن هم باید واقعاً 404 باشد.

این پرامپت کمک می‌کند تصمیم بگیرید با هر آدرس 404 چه کنید:

این آدرس‌ها در سایت من خطای 404 می‌دهند (از Search Console یا گزارش سرور):
[فهرست آدرس‌ها]
ساختار آدرس‌های سایت: [مثلاً /blog/نامک یا /دسته/نامک].
تغییرات اخیر: [تغییر نامک، حذف صفحه، انتقال سایت].
برای هر آدرس بگو احتمالاً چرا 404 شده و کدام اقدام بهتر است: ریدایرکت 301 به صفحهٔ مرتبط، پاسخ 410 یا نگه‌داشتن همان 404.
برای ریدایرکت، مقصد پیشنهادی را از این صفحه‌های موجود انتخاب کن: [فهرست صفحه‌های موجود].

خطای 405؛ روش درخواست مجاز نیست

پیام 405 Method Not Allowed یعنی روش درخواست برای آن منبع پشتیبانی نمی‌شود. برای مثال، مسیری فقط POST می‌پذیرد، اما درخواست با GET ارسال شده است. جزئیات در صفحهٔ خطای 405 در MDN آمده است.

این وضعیت بیشتر هنگام ارسال فرم یا اتصال یک برنامه به API دیده می‌شود. کاربر معمولاً با بازگشت به فرم اصلی و ارسال دوباره از مسیر عادی سایت مشکل را دور می‌زند.

توسعه‌دهنده باید روش فرم، تعریف مسیر در برنامه و محدودیت‌های وب‌سرور را بررسی کند. خوشبختانه هدر Allow در پاسخ 405 روش‌های مجاز را مشخص می‌کند و سرنخ مستقیمی می‌دهد.

برای بررسی این خطا، این پرامپت را استفاده کنید:

درخواست [روش، مثلاً GET یا POST] به [آدرس] پاسخ 405 Method Not Allowed می‌گیرد.
هدر Allow در پاسخ: [مقدار].
فریم‌ورک یا CMS: [نام] و تعریف مسیر در کد: [کد مسیر یا فرم].
درخواست از [فرم سایت / برنامهٔ دیگر / ابزار تست API] ارسال می‌شود.
بگو ناهماهنگی بین روش ارسال و تعریف مسیر کجاست و چطور درستش کنم.

خطای 408؛ دریافت درخواست بیش از حد طول کشیده

پیام 408 Request Timeout یعنی سرور در مدتی که منتظر مانده، درخواست کامل را دریافت نکرده است. اتصال ناپایدار یا ارسال بسیار کند داده از علت‌های رایج آن است. توضیح رسمی در صفحهٔ خطای 408 در MDN آمده است.

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

تفاوت 408 با 504 در محل انتظار است. در 408 سرور منتظر تکمیل درخواست ورودی بوده است. اما در 504 واسطه منتظر پاسخ سرور بعدی مانده است.

این پرامپت کمک می‌کند بفهمید مشکل از اتصال کاربر است یا تنظیمات سرور:

کاربران سایت من هنگام [ارسال فرم / آپلود فایل / عملیات دیگر] خطای 408 Request Timeout می‌گیرند.
حجم تقریبی داده یا فایل: [حجم]. نوع اتصال کاربران: [موبایل / ثابت / نامشخص].
تنظیمات مهلت فعلی سرور و CDN: [مقادیر، اگر می‌دانید].
بگو این الگو بیشتر به اتصال کند کاربر شبیه است یا به مهلت کوتاه سرور.
برای هر دو حالت یک آزمایش ساده پیشنهاد بده.

خطای 409؛ تعارض با وضعیت فعلی اطلاعات

پیام 409 Conflict یعنی درخواست با وضعیت فعلی منبع تعارض دارد. نمونهٔ آشنای آن، ذخیره کردن نسخهٔ قدیمی یک مطلب بعد از اینکه فرد دیگری آن را تغییر داده است. جزئیات در صفحهٔ خطای 409 در MDN آمده است.

کاربر باید آخرین نسخهٔ اطلاعات را دریافت کند، تغییرات را مقایسه کند و سپس دوباره ذخیره کند. در غیر این صورت، ممکن است تغییرات یکی از دو نفر از بین برود.

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

این پرامپت برای طراحی راه‌حل تعارض مناسب است:

در برنامهٔ من هنگام [ذخیرهٔ مطلب / ثبت سفارش / به‌روزرسانی موجودی] خطای 409 Conflict رخ می‌دهد.
این عملیات [توسط چند کاربر هم‌زمان / با تلاش دوبارهٔ خودکار] انجام می‌شود.
پیام پاسخ سرور: [پیام].
بگو تعارض دقیقاً بین کدام دو وضعیت است.
یک روش پیشنهاد بده که کاربر تغییرات را ببیند و تصمیم بگیرد، بدون اینکه داده‌ای از بین برود.

خطای 410؛ منبع حذف شده است

پیام 410 Gone اعلام می‌کند منبع دیگر وجود ندارد و این وضعیت احتمالاً دائمی است. برخلاف 404، این کد صریحاً به موتور جست‌وجو می‌گوید دنبال آن صفحه نگردد. توضیح رسمی در صفحهٔ خطای 410 در MDN آمده است.

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

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

برای تصمیم دربارهٔ صفحه‌های حذف‌شده، این پرامپت را بپرسید:

این صفحه‌ها را از سایتم حذف کرده‌ام: [فهرست آدرس‌ها با موضوع هرکدام].
صفحه‌های مرتبط موجود: [فهرست].
برای هر آدرس بگو پاسخ 410 مناسب‌تر است یا ریدایرکت 301 به یک صفحهٔ مرتبط.
دلیل هر انتخاب را از نظر تجربهٔ کاربر و سئو در یک جمله بنویس.

خطای 413؛ حجم درخواست بیش از حد مجاز است

پیام 413 Content Too Large یعنی بدنهٔ درخواست از حدی که سرور می‌پذیرد بزرگ‌تر است. آپلود فایل حجیم رایج‌ترین موقعیت آن است. جزئیات را در صفحهٔ خطای 413 در MDN ببینید.

بازدیدکننده می‌تواند فایل را کوچک‌تر یا فشرده کند و محدودیت اعلام‌شدهٔ سایت را بررسی کند.

مدیر سایت باید همهٔ لایه‌ها را بررسی کند: CDN، پراکسی، وب‌سرور و برنامه. برای مثال، افزایش محدودیت فقط در PHP کافی نیست اگر Nginx یا CDN درخواست را زودتر رد کند. همچنین محدودیت جدید باید با فضای ذخیره‌سازی و توان پردازش سایت سازگار باشد.

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

هنگام آپلود فایل [حجم] مگابایتی در سایتم خطای 413 Content Too Large می‌گیرم.
مسیر درخواست: [مثلاً CDN ← Nginx ← PHP ← برنامه].
تنظیمات فعلی که می‌دانم: [upload_max_filesize، post_max_size، client_max_body_size، محدودیت CDN].
بگو در هر لایه کدام تنظیم حجم را محدود می‌کند و چطور بفهمم کدام لایه درخواست را رد کرده است.
سقف پیشنهادی را با توجه به نیاز واقعی [نوع فایل‌ها] توضیح بده.

خطای 414؛ آدرس بیش از حد طولانی است

پیام 414 URI Too Long یعنی نشانی درخواست از حد پذیرفته‌شده طولانی‌تر است. توضیح رسمی آن در صفحهٔ خطای 414 در MDN آمده است.

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

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

برای پیدا کردن منشأ آدرس طولانی، این پرامپت را استفاده کنید:

بعضی صفحه‌های سایتم خطای 414 URI Too Long می‌دهند.
نمونهٔ آدرس طولانی: [آدرس، بدون اطلاعات شخصی].
این آدرس از [فیلتر جست‌وجو / فرم / لینک تولیدشده با کد] ساخته می‌شود.
بگو کدام بخش آدرس بی‌دلیل تکرار یا بزرگ شده است.
یک راه ساخت آدرس کوتاه‌تر یا ارسال داده در بدنهٔ درخواست پیشنهاد بده.

خطای 415؛ نوع محتوای ارسالی پشتیبانی نمی‌شود

پیام 415 Unsupported Media Type یعنی سرور قالب محتوای درخواست را برای آن عملیات نمی‌پذیرد. جزئیات در صفحهٔ خطای 415 در MDN آمده است.

برای مثال، API انتظار JSON دارد، اما برنامه داده را به‌صورت فرم می‌فرستد. یا اینکه فرمت فایل آپلودشده، مثلاً HEIC، پشتیبانی نمی‌شود.

کاربر باید از فرمت‌های مجاز استفاده کند. توسعه‌دهنده نیز باید بدنهٔ واقعی، هدر Content-Type و قالب‌های پذیرفته‌شده را با هم تطبیق دهد. البته تغییر هدر بدون تبدیل واقعی داده مشکل را حل نمی‌کند.

این پرامپت ناهماهنگی قالب داده را پیدا می‌کند:

درخواست من به [آدرس API] پاسخ 415 Unsupported Media Type می‌گیرد.
هدر Content-Type ارسالی: [مقدار].
نمونهٔ بدنه: [بدنه یا نوع فایل].
مستندات API دربارهٔ قالب ورودی می‌گوید: [متن مستندات].
بگو قالب واقعی داده با آنچه سرور انتظار دارد کجا فرق دارد و کد ارسال را چطور اصلاح کنم.

خطای 422؛ محتوای درخواست قابل پردازش نیست

پیام 422 Unprocessable Content یعنی سرور قالب و ساختار داده را می‌فهمد، اما محتوای آن با قواعد برنامه جور نیست. توضیح رسمی در صفحهٔ خطای 422 در MDN آمده است.

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

در مقابل، توسعه‌دهنده باید دقیقاً بگوید کدام مقدار و به چه دلیل پذیرفته نشده است. نمایش عدد 422 بدون توضیح، کاربر را سردرگم می‌کند.

این پرامپت برای خواندن پیام‌های اعتبارسنجی و نوشتن پیام بهتر کاربرد دارد:

فرم [نام فرم] در سایتم پاسخ 422 Unprocessable Content برمی‌گرداند.
داده‌های ارسالی: [فیلدها و مقادیر نمونه، بدون اطلاعات شخصی].
متن پاسخ سرور: [پیام‌های اعتبارسنجی].
بگو کدام فیلدها رد شده‌اند و چرا.
برای هر خطا یک پیام کوتاه و روشن فارسی پیشنهاد بده که کنار همان فیلد به کاربر نشان داده شود.

خطای 429؛ تعداد درخواست‌ها بیش از حد مجاز است

پیام 429 Too Many Requests یعنی تعداد درخواست‌های یک کاربر یا برنامه در بازه‌ای مشخص از حد مجاز گذشته است. پاسخ ممکن است هدر Retry-After هم داشته باشد. جزئیات در صفحهٔ خطای 429 در MDN آمده است.

تازه‌سازی مکرر، تلاش‌های زیاد برای ورود یا ارسال پرتعداد درخواست توسط یک برنامه می‌تواند عامل آن باشد. گاهی هم چند کاربر پشت یک IP مشترک، مثل شبکهٔ یک اداره، روی محدودیت یکدیگر اثر می‌گذارند.

کاربر بهتر است مدتی صبر کند. برنامه‌های متصل به API هم باید فاصلهٔ تلاش‌ها را به‌تدریج بیشتر کنند. مدیر سایت نیز باید تناسب محدودیت با ترافیک واقعی را بررسی کند تا کاربران عادی بی‌دلیل مسدود نشوند.

این پرامپت به تنظیم منصفانهٔ محدودیت کمک می‌کند:

کاربران یا برنامهٔ من هنگام [عملیات] خطای 429 Too Many Requests می‌گیرند.
محدودیت فعلی: [مثلاً 60 درخواست در دقیقه برای هر IP] در [برنامه / CDN / API خارجی].
الگوی درخواست‌ها: [تعداد، فاصله، تلاش دوبارهٔ خودکار].
هدر Retry-After در پاسخ: [مقدار یا ندارد].
بگو مشکل از الگوی ارسال درخواست است یا از سخت‌گیری محدودیت.
اگر کد ارسال مشکل دارد، یک روش تلاش دوباره با فاصلهٔ افزایشی پیشنهاد بده.

خطای 431؛ هدرهای درخواست بیش از حد بزرگ‌اند

پیام 431 Request Header Fields Too Large به بزرگ‌بودن یک هدر یا مجموع هدرهای درخواست مربوط است. کوکی‌های حجیم رایج‌ترین علت آن هستند. توضیح رسمی را در صفحهٔ خطای 431 در MDN ببینید.

کاربر می‌تواند ابتدا سایت را در پنجرهٔ خصوصی امتحان کند. اگر آنجا درست کار کرد، پاک کردن کوکی‌های همان سایت احتمالاً مشکل را حل می‌کند؛ البته ممکن است از حساب خارج شود.

مدیر سایت باید جلوی ذخیرهٔ اطلاعات زیاد در کوکی‌ها را بگیرد. همچنین رشد غیرعادی هدرها، مثلاً کوکی‌هایی که با هر بازدید بزرگ‌تر می‌شوند، باید بررسی شود.

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

سایت من برای بعضی کاربران خطای 431 Request Header Fields Too Large می‌دهد.
در پنجرهٔ خصوصی مرورگر خطا [رخ می‌دهد / رخ نمی‌دهد].
فهرست کوکی‌های سایت و اندازهٔ تقریبی هرکدام: [فهرست، بدون مقدار کوکی].
افزونه‌ها یا سرویس‌هایی که کوکی می‌سازند: [فهرست].
بگو کدام کوکی احتمالاً بی‌رویه بزرگ شده و چطور جلوی رشد آن را بگیرم.

چند خطای کمتر رایج

کدهای زیر کمتر دیده می‌شوند و بیشتر هنگام توسعهٔ API، تنظیم سرور یا کار با سرویس‌های خاص پیش می‌آیند. با این حال، شناختن معنای کلی آن‌ها زمان عیب‌یابی را کوتاه می‌کند.

معنای استاندارد این کدها در مشخصات HTTP، سند RFC 9110 آمده است. اگر با یکی از آن‌ها روبه‌رو شدید، این پرامپت عمومی را با همان کد پر کنید:

در سایت یا API من خطای HTTP با کد [کد] و پیام [متن پیام] رخ می‌دهد.
درخواست: [روش، آدرس و هدرهای مهم، بدون توکن].
مسیر درخواست: [مرورگر یا برنامه ← CDN ← وب‌سرور ← برنامه].
ابتدا معنی استاندارد این کد را در دو جمله توضیح بده.
سپس بگو کدام لایه احتمالاً آن را تولید کرده و سه بررسی ساده برای تأیید پیشنهاد بده.

خطاهای 520 تا 526 در Cloudflare

در سایت‌هایی که از Cloudflare استفاده می‌کنند، گاهی کدهایی دیده می‌شوند که در استاندارد HTTP نیستند. این کدها را خود Cloudflare می‌سازد و به ارتباط آن با سرور اصلی سایت مربوط‌اند. سرویس‌های مشابه، مانند CDNهای ایرانی، هم صفحه‌ها و کدهای خطای مخصوص خود را دارند.

این کدها را باید با مستندات همان سرویس تفسیر کرد. برای مثال، در مشکلات گواهی، اصلاح گواهی روی سرور اصلی راه‌حل اصلی است. جزئیات بیشتر در راهنمای خطاهای 5xx در Cloudflare آمده است.

برای بررسی این خطاها با هوش مصنوعی، این پرامپت را استفاده کنید:

سایت من پشت [Cloudflare / نام CDN] است و خطای [کد، مثلاً 521 یا 522] نمایش می‌دهد.
IP سرور اصلی در تنظیمات DNS: [درست است / مطمئن نیستم].
حالت SSL در CDN: [Flexible / Full / Full Strict] و گواهی سرور اصلی: [نوع و تاریخ انقضا].
وقتی سایت را مستقیم با IP سرور باز می‌کنم: [نتیجه].
بگو مشکل در ارتباط CDN با سرور اصلی است یا در خود سرور، و به ترتیب چه چیزهایی را بررسی کنم.

آیا 301، 302 و 304 هم خطا هستند؟

معمولاً خیر. کدهای تغییر مسیر و کش بخشی از رفتار عادی وب هستند. برای مثال، 301 برای انتقال دائمی و 302 برای انتقال موقت استفاده می‌شود. کدهای 307 و 308 هم انتقال را با حفظ روش درخواست انجام می‌دهند و 304 یعنی مرورگر می‌تواند از نسخهٔ ذخیره‌شده استفاده کند.

مشکل وقتی پیش می‌آید که تنظیمات تغییر مسیر با هم تداخل داشته باشند. برای مثال، یک قانون کاربر را از HTTP به HTTPS می‌فرستد و قانون دیگری او را برمی‌گرداند. نتیجه، پیام ERR_TOO_MANY_REDIRECTS در مرورگر است.

در چنین وضعیتی، مدیر سایت باید زنجیرهٔ انتقال‌ها، نشانی اصلی سایت و هماهنگی تنظیمات برنامه، وب‌سرور و CDN را بررسی کند. راهنمای کامل را در صفحهٔ تغییر مسیر در MDN ببینید.

برای پیدا کردن حلقهٔ ریدایرکت، این پرامپت را بپرسید:

سایت من در مرورگر خطای ERR_TOO_MANY_REDIRECTS می‌دهد.
زنجیرهٔ ریدایرکت‌ها (از ابزار Network یا یک بررسی‌کنندهٔ ریدایرکت): [آدرس ← کد ← آدرس بعدی ...].
جاهایی که ریدایرکت تعریف شده: [تنظیمات CMS، htaccess یا Nginx، قوانین CDN].
حالت SSL در CDN: [مقدار] و نشانی اصلی سایت در تنظیمات: [آدرس].
بگو حلقه از تداخل کدام دو قانون ساخته شده و کدام‌یک باید تغییر کند.

خطای CORS چیست؟

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

CORS کد وضعیت HTTP نیست. قواعدی است که مشخص می‌کند کدِ یک دامنه اجازه دارد پاسخ دامنهٔ دیگری را بخواند یا نه. جزئیات علت معمولاً در Console مرورگر نوشته می‌شود و راهنمای آن در صفحهٔ خطاهای CORS در MDN آمده است.

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

این پرامپت کمک می‌کند تنظیم درست CORS را پیدا کنید:

در Console مرورگر این خطای CORS را می‌بینم: [متن کامل پیام].
صفحه روی دامنهٔ [دامنهٔ مبدأ] است و درخواست به [دامنهٔ مقصد و مسیر] ارسال می‌شود.
روش درخواست و هدرهای سفارشی: [روش و هدرها]. کوکی یا اعتبارنامه ارسال [می‌شود / نمی‌شود].
هدرهای پاسخ سرور مقصد: [هدرها].
بگو دقیقاً کدام هدر پاسخ کم است یا اشتباه تنظیم شده و مقدار درست آن چیست.
راه‌حلی مثل مجاز کردن همهٔ دامنه‌ها با * برای درخواست‌های دارای کوکی پیشنهاد نده.

برای پیدا کردن علت واقعی خطا از کجا شروع کنیم؟

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

ابتدا این اطلاعات را یادداشت کنید:

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

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

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

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

اشتباه‌های رایج هنگام رفع خطاهای سایت

عجله در رفع خطا اغلب وضعیت را بدتر می‌کند. این اشتباه‌ها را زیاد می‌بینیم:

• پاک کردن کش برای هر خطا: کش یا کوکی گاهی مؤثر است، اما خرابی برنامه یا پایگاه داده را برطرف نمی‌کند.
• راه‌اندازی مجدد بدون خواندن گزارش‌ها: ممکن است سایت برگردد، اما علت باقی بماند و خطا دوباره پیدا شود.
• افزایش بی‌حساب زمان انتظار: پردازش کند را اصلاح نمی‌کند و درخواست‌های بیشتری را معطل نگه می‌دارد.
• خاموش کردن کامل ابزارهای امنیتی: بهتر است قانون مسدودکننده پیدا و دقیق اصلاح شود.
• نمایش جزئیات فنی به بازدیدکننده: گزارش کامل برای تیم فنی است؛ کاربر به پیام روشن و شناسهٔ پیگیری نیاز دارد.
• اجرای بی‌چون‌وچرای پاسخ هوش مصنوعی: پیشنهاد مدل یک فرضیه است؛ آن را اول روی نسخهٔ آزمایشی یا با یک بررسی کم‌خطر امتحان کنید.
• تکرار کورکورانهٔ عملیات حساس: بعد از خطای پرداخت یا ثبت سفارش، اول نتیجهٔ تلاش قبلی را مشخص کنید.

اگر می‌خواهید پرامپت‌های عیب‌یابی خودتان را هم دقیق‌تر بنویسید، اصول پایهٔ پرامپت‌نویسی کمک زیادی می‌کند.

بیشتر بخوانید: آموزش پرامپت نویسی از صفر؛ اصول مهندسی پرامپت با مثال

خطاهای سایت چه اثری بر سئو دارند؟

وجود چند آدرس 404 به‌خودی‌خود به معنی خراب بودن سئوی سایت نیست. وقتی صفحه‌ای واقعاً حذف شده، پاسخ 404 یا 410 رفتار درستی است.

مسئلهٔ مهم این است که صفحه‌های موردنیاز کاربران و موتور جست‌وجو به‌اشتباه خطا ندهند. همچنین تداوم خطاهای 5xx باعث کاهش خزش می‌شود و اگر ادامه پیدا کند، صفحه‌ها ممکن است از نتایج گوگل حذف شوند.

علاوه بر این، صفحه‌ای که پیام «پیدا نشد» نشان می‌دهد اما کد 200 برمی‌گرداند، ممکن است به‌عنوان Soft 404 شناخته شود. پس ظاهر صفحه و کد واقعی پاسخ باید با هم سازگار باشند. گوگل این موضوع را در راهنمای اثر کدهای HTTP بر خزش و ایندکس توضیح داده است.

چطور از تکرار خطاهای سایت جلوگیری کنیم؟

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

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

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

برای گزارش خطا به پشتیبانی چه بنویسیم؟

گزارش دقیق، زمان رفع مشکل را کوتاه می‌کند. به‌جای «سایت خراب است»، گزارشی مانند این بفرستید:

هنگام باز کردن صفحهٔ مشخصات سفارش در ساعت ۱۴:۳۵، خطای 503 دریافت کردم. صفحهٔ اصلی باز می‌شود، اما این بخش همچنان خطا دارد. مشکل را در دو مرورگر مشاهده کردم. شناسهٔ درخواست نمایش‌داده‌شده نیز … است.

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

سخن پایانی

خطاهای سایت ترسناک به نظر می‌رسند، اما در واقع زبان سرور برای گفتن «کجا گیر کرده‌ام» هستند. خانوادهٔ 4xx معمولاً شما را به سمت درخواست، دسترسی یا آدرس می‌برد. در مقابل، خانوادهٔ 5xx می‌گوید باید سراغ سرور، برنامه و سرویس‌های پشت آن بروید.

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

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