اگر صفحهٔ اصلی وردپرس باز میشود اما نوشتهها و برگه‌های موجود ۴۰۴ میدهند، ابتدا مسیر رسیدن درخواست به وردپرس و سپس قواعد پیوند یکتا را بررسی کنید. ذخیرهٔ دوبارهٔ همان تنظیمات، پس از تهیهٔ نسخهٔ بازگشت، ممکن است قواعد را تازه کند؛ تغییر ساختار نشانی یا انتقال همهٔ خطاها به خانه راه‌حل این عیب نیست.
راه‌حل سریع و ایمن
- سه نشانی ثبت کنید: خانه، یک نوشتهٔ منتشرشده که اکنون خراب است و یک مسیر ساختگی که واقعاً وجود ندارد. کد پاسخ هر سه را در ابزار شبکهٔ مرورگر ببینید و تصویر صفحه را جایگزین کد پاسخ نکنید.
- در پیشخوان، وجود و وضعیت انتشار همان نوشته را کنترل کنید. اگر فقط یک نوشته حذف یا پیش‌نویس شده، ابتدا تکلیف محتوا را روشن کنید؛ این وضعیت بهتنهایی دلیل خرابی پیوندهای یکتا نیست.
- از ساختار فعلی پیوند یکتا، فایل پیکربندی مرتبط و تنظیمات افزونهٔ تغییر مسیر نسخهٔ بازگشت بگیرید. در فروشگاه فعال، زمان تغییر را با مسئول سفارش‌ها هماهنگ کنید و آزمایش گسترده را به محیط آزمایشی ببرید.
- اگر مشکل عمومی مسیرهای داخلی است، در تنظیمات پیوندهای یکتا، بدون انتخاب ساختاری متفاوت، یک بار ذخیره کنید. یک نشانی خراب را دوباره با درخواست تازه بررسی کنید؛ ذخیرهٔ پیاپی اطلاعات تشخیصی تازه‌ای نمی‌سازد.
- اگر نتیجه تغییر نکرد، نوع وب‌سرور را از پنل یا پشتیبانی میزبان بپرسید. در Apache خوانده‌شدن قواعد بازنویسی و در nginx رسیدن مسیرهای مجازی به ورودی وردپرس باید بررسی شود؛ کپی فایل یکی به دیگری کافی نیست.
- پس از اصلاح همان علت، کش مسیرهای درگیر را هدفمند پاک کنید. نوشته، دسته، محصول، صفحه‌بندی و یک نشانی ناموجود را جداگانه امتحان کنید تا تعمیر مسیرهای موجود باعث نمایش موفقیت کاذب برای مسیرهای حذفشده نشده باشد.
- اگر نشانی واقعاً جابه‌جا شده، مقصد هم‌معنا را تعیین کنید و فقط همان نگاشت را بسازید. اگر جایگزینی وجود ندارد، پاسخ درست ۴۰۴ یا در حذف عمدی متناسب با سیاست سایت ۴۱۰ را نگه دارید و لینک‌های داخلی خراب را اصلاح کنید.
پیش از تغییر، دامنهٔ خرابی را قابل اندازه‌گیری کنید
عبارت «همهٔ صفحه‌ها خراب شده» برای شروع گفت‌وگو مفید است، اما برای انتخاب اصلاح کافی نیست. چند نمونه از انواع مختلف محتوا انتخاب کنید: نوشته‌ای قدیمی، برگهٔ معرفی، آرشیو دسته و در صورت وجود محصول. کنار هر نمونه، زمان آخرین مشاهدهٔ سالم، وضعیت فعلی و روش ورود کاربر را یادداشت کنید. صفحه‌ای که از منو باز نمی‌شود ممکن است با نشانی درست خود سالم باشد؛ در این حالت مشکل لینک منو است و نه موتور مسیریابی.
نمونه‌ها را با یک درخواست تازه و بدون اتکا به نتیجهٔ موتور جست‌وجو باز کنید. نتیجهٔ قدیمی جست‌وجو میتواند نشانی پیش از تغییر نامک را نشان دهد. همچنین کپی نشانی از پیام‌رسان گاهی فاصله، نشانهٔ پایانی یا نویسهٔ نامرئی اضافه می‌کند. آدرسی را که مرورگر واقعاً درخواست کرده ثبت کنید، نه فقط متنی را که روی لینک نوشته شده است. اگر مسیر فارسی است، نسخهٔ خوانا و نسخهٔ رمزگذاری‌شده باید به یک منبع اشاره کنند و تفاوت ظاهری آنها بهتنهایی خرابی نیست.
این دفترچهٔ کوچک، مبنای پذیرش تعمیر خواهد بود. بعد از هر تغییر دقیقاً همان نمونه‌ها را تکرار کنید تا بهبود یک مسیر باعث فراموشی خرابی دیگری نشود. تغییر هم‌زمان چند تنظیم، امکان نسبت‌دادن نتیجه به علت را از بین می‌برد؛ حتی اگر سایت موقتاً باز شود، علت بازگشت مشکل ناشناخته می‌ماند.
دسترسی لازم و نسخهٔ بازگشت متناسب با عملیات
برای مشاهدهٔ وضعیت انتشار و ذخیرهٔ پیوند یکتا، دسترسی مدیریتی وردپرس لازم است؛ برای بررسی قواعد سرور ممکن است پنل میزبانی یا همکاری مدیر سرور کافی باشد. داشتن رمز مدیریت به معنای اجازهٔ ویرایش همهٔ لایه‌ها نیست. مشخص کنید چه کسی فایل فعال وب‌سرور را می‌شناسد، چه کسی میتواند پیکربندی قبلی را برگرداند و چه کسی سفارش‌های تازه را زیر نظر می‌گیرد. اطلاعات ورود را در تیکت عمومی، خروجی ترمینال یا تصویر آموزشی قرار ندهید.
پیش از ذخیره، از صفحهٔ تنظیمات تصویر بگیرید و متن ساختار فعلی را جداگانه نگه دارید. پیش از ویرایش فایل، نسخهٔ همان فایل و محل استفادهٔ آن را ثبت کنید؛ دانلود یک فایل با نام مشابه از پوشه‌ای دیگر، نسخهٔ بازگشت معتبر نمی‌سازد. اگر تغییر به پایگاه داده مربوط میشود، نسخهٔ پشتیبان سازگار و امکان بازیابی آن باید روشن باشد. برای تغییر صرفاً مسیریابی، بازگرداندن کل پایگاه دادهٔ فروشگاه میتواند سفارش‌های بعد از پشتیبان را حذف کند و نباید نخستین واکنش باشد.
محیط آزمایشی را از ارسال پیام، پرداخت واقعی و ایندکس عمومی جدا کنید. سپس همان پیکربندی مؤثر بر مسیرها را تا حد امکان بازسازی کنید؛ محیطی که بدون پراکسی و با وب‌سروری متفاوت اجرا میشود فقط بخشی از فرضیه را می‌آزماید. نتیجهٔ آن را با همین محدودیت تفسیر کنید. برای برنامه‌ریزی مسیر رسیدگی و تعیین مسئول تغییر، پشتیبانی وردپرس میتواند نقطهٔ بعدی بررسی باشد.
فرق صفحهٔ گمشده با خطای مسیریابی سراسری
۴۰۴ دربارهٔ منبع درخواستی است: مسیر موردنظر پیدا نشده یا به آن پاسخ مناسبی داده نشده است. ظاهر صفحه تعیین نمی‌کند کدام لایه تصمیم گرفته؛ قالب میتواند صفحهٔ خطای زیبایی بسازد و سرور هم میتواند صفحه‌ای ساده نشان دهد. برای تصمیم اولیه، پاسخ خانه را با یک نوشتهٔ موجود مقایسه کنید. اگر هر دو خطای اتصال یا خطای داخلی دارند، مسئله گسترده‌تر از پیوند یکتا است و لازم است مسیر خطای داخلی ۵۰۰ وردپرس را نیز بررسی کنید.
اگر همهٔ نوشتهها سالم‌اند اما یک برگهٔ حذفشده خطا دارد، بازسازی قواعد بعید است همان محتوا را برگرداند. زباله‌دان، وضعیت خصوصی، زمان‌بندی انتشار و تغییر نامک را کنترل کنید. گاهی مدیر واردشده پیش‌نمایش را می‌بیند اما بازدیدکنندهٔ مهمان حق مشاهده ندارد؛ در این حالت «برای من باز میشود» شاهد انتشار عمومی نیست. لینک پیش‌نمایش را نیز نباید به‌عنوان نشانی نهایی در منو یا شبکهٔ اجتماعی قرار داد.
در مقابل، سالمبودن خانه همراه با خرابی بیشتر مسیرهای خوانا، به مسیر پردازش درخواست اشاره می‌کند. هنوز نباید نتیجه گرفت فایل خاصی خراب است؛ انتقال سرور، جابه‌جایی زیرپوشه، قواعد افزونه و کش لبه هم می‌توانند همین الگو را بسازند. ارزش این تفکیک در محدودکردن شاخه‌ها است، نه اعلام علت قطعی پیش از مشاهدهٔ تنظیمات.
درخت تصمیم از وضعیت محتوا تا ورودی وردپرس
ابتدا بپرسید آیا محتوا در پیشخوان وجود دارد و منتشر است. اگر پاسخ منفی است، تصمیم تحریریه لازم دارید: بازیابی، انتشار یا پذیرش حذف. اگر پاسخ مثبت است، نشانی تولیدشده توسط خود وردپرس را از گزینهٔ مشاهده بردارید. چنانچه آن نشانی سالم و نشانی داخل منو خراب باشد، لینک مصرف‌کننده را اصلاح کنید. این آزمون ساده بسیاری از اختلاف‌های ناشی از نامک قدیمی را بدون تغییر پیکربندی حل می‌کند.
اگر نشانی تولیدشده هم خراب است، گستره را بررسی کنید. خرابی فقط یک نوع نوشته به ثبت آن نوع محتوا یا تداخل پایهٔ نشانی مشکوک است؛ خرابی همهٔ مسیرهای خوانا، بازنویسی و ورودی سایت را جلو می‌اندازد. اگر پاسخ بین دو نشانی جابه‌جا میشود و هرگز به صفحه نمی‌رسد، دیگر یک ۴۰۴ ساده ندارید؛ راهنمای ریدایرکت بیش از حد وردپرس برای آن شاخه مناسب‌تر است.
در شاخهٔ عمومی، یک بار قواعد پیوند یکتا را با همان ساختار تازه کنید. بهبود پایدار، فرضیهٔ قواعد قدیمی را تقویت می‌کند؛ بی‌اثرماندن آن، بررسی وب‌سرور را ضروری می‌کند. در شاخهٔ محدود، افزونهٔ ثبت‌کنندهٔ محتوا، زبان، فروشگاه یا قواعد سفارشی را در محیط آزمایشی بررسی کنید. ترتیب این درخت باعث میشود تغییر بزرگ فقط پس از رد آزمون کوچک‌تر انجام شود.
ذخیرهٔ پیوند یکتا بدون تغییر قرارداد نشانی‌ها
در تنظیمات، رشتهٔ فعلی را بخوانید و همان را نگه دارید. انتخاب یک گزینهٔ دیگر برای «امتحان» میتواند نشانی تمام نوشتهها را عوض کند و مشکل تازه‌ای به مشکل اول بیفزاید. طبق مستند رسمی تنظیمات پیوند یکتا، این بخش محل تعیین ساختار نشانی‌ها و پایه‌های مرتبط است. هدف ما در این مرحله تغییر این قرارداد نیست؛ فقط می‌خواهیم قواعد منطبق با قرارداد موجود دوباره تولید شوند.
پس از ذخیره، پیام صفحه را دقیق بخوانید. موفقیت ذخیرهٔ گزینه‌ها لزوماً اثبات نمی‌کند فایل پیکربندی قابل نوشتن بوده یا سرور آن را مصرف می‌کند. اگر پیام راهنمای ویرایش دستی می‌بینید، متن آن را با مدیر میزبان بررسی کنید و فایل را کورکورانه جایگزین نکنید. در نصب زیرپوشه، چندسایتی یا ساختاری با قواعد اختصاصی، نمونهٔ عمومی ممکن است مسیر پایهٔ مناسب شما را نداشته باشد.
بلافاصله یک درخواست تازه برای نوشتهٔ نمونه بفرستید و سپس مسیر ناموجود کنترل را امتحان کنید. اگر هر دو خانه را با پاسخ موفق نشان میدهند، تعمیر درست انجام نشده است. اگر فقط چند دقیقه سالم می‌ماند، زمان بازگشت را ثبت کنید؛ ممکن است کار زمان‌بندی‌شده یا افزونه‌ای قواعد را دوباره تغییر دهد. ذخیرهٔ روزانه به‌عنوان درمان دائمی، نشانهٔ باقی‌ماندن علت است و باید مسیر بازنویسی مجدد شناسایی شود.
Apache؛ خوانده‌شدن قواعد مهم‌تر از وجود فایل است
در Apache صرف وجود فایل .htaccess در پوشه‌ای روی حساب میزبانی کافی نیست. باید معلوم باشد ریشهٔ همین دامنه کجاست، درخواست به کدام میزبان مجازی می‌رسد و سیاست سرور اجازهٔ اعمال قواعد آن پوشه را میدهد یا نه. فایل قدیمی در پوشهٔ نسخهٔ قبلی سایت میتواند ظاهراً درست باشد و هیچ اثری بر درخواست واقعی نگذارد. از مدیر میزبان بخواهید مسیر مؤثر را تأیید کند، نه اینکه فقط وجود نام فایل را گزارش دهد.
مقدمهٔ رسمی mod_rewrite توضیح میدهد که بازنویسی میتواند در زمینه‌های مختلف پیکربندی انجام شود. در عیب‌یابی عملی، زمینه و ترتیب قواعد تعیین می‌کند یک الگو کجا و چگونه اعمال شود. به همین دلیل انتقال چند خط از تنظیمات میزبان مجازی به فایل پوشه بدون بررسی پیشوند مسیر، آزمایش قابل اتکایی نیست. همچنین پیکربندی سرویس دیگری در جلوی Apache ممکن است پیش از رسیدن درخواست تصمیم بگیرد.
فایل موجود را با نسخهٔ پیش از خرابی مقایسه کنید و قواعد اختصاصی تغییر مسیر، کنترل دسترسی و کش را از بلوک مدیریت‌شدهٔ وردپرس تشخیص دهید. حذف کل فایل میتواند رفتارهایی را که مسئول دیگری تنظیم کرده از بین ببرد. حداقل تغییر مرتبط را در محیط آزمایشی اعمال کنید، صحت پیکربندی را با ابزار مورد استفادهٔ مدیر سرور بررسی کنید و فقط پس از نتیجهٔ روشن برای اعمال کنترل‌شده اقدام کنید. افزایش عمومی مجوز فایل راه تشخیص بازنویسی نیست.
nginx؛ مسیر مجازی باید به کنترل‌کنندهٔ درست برسد
nginx فایل .htaccess را مانند Apache مصرف نمی‌کند. بنابراین تکرار ساختن آن فایل در سایتی که مستقیماً با nginx سرو میشود، علت مسیریابی را عوض نخواهد کرد. در این لایه باید بلوک فعال دامنه، ریشهٔ فایل‌ها و قواعد انتخاب مسیر بررسی شوند. در نصب معمول وردپرس، بسیاری از نشانیهای نوشته فایل فیزیکی هم‌نام ندارند و لازم است پس از بررسی منابع واقعی، درخواست به ورودی برنامه برسد.
مرجع رسمی try_files در nginx رفتار بررسی وجود فایل و مقصد نهایی را شرح میدهد. این مرجع بهتنهایی نسخهٔ آمادهٔ پیکربندی سایت شما نیست. مدیر سرور باید تشخیص دهد مقصد نهایی با محل نصب، پارامترهای درخواست و پردازش PHP سازگار است. اگر وردپرس در زیرپوشه نصب شده یا چند برنامه یک دامنه را تقسیم کرده‌اند، فرستادن همهٔ مسیرها به ورودی ریشه میتواند برنامهٔ اشتباه را فعال کند.
از مدیر میزبان بخواهید برای نشانی نمونه توضیح دهد کدام بلوک مسیر انتخاب میشود و در نبود فایل واقعی، درخواست به کجا می‌رود. اگر در همان مرحله پاسخ ۴۰۴ صادر میشود، ذخیرهٔ تنظیمات وردپرس این تصمیم را تغییر نمیدهد. پس از اصلاح، منابع واقعی مانند تصویر و فایل سبک نیز باید مستقیم و سالم بمانند. پاسخ HTML وردپرس به جای یک تصویر، حتی با کد موفق، نشانهٔ پیکربندی درست نیست.
خواندن پاسخ بدون تغییر دادن سایت
برای بررسی اولیه نیازی به نصب افزونهٔ عیب‌یابی یا روشن‌کردن خروجی خطا برای بازدیدکنندگان ندارید. در ابزار توسعهٔ مرورگر، زبانهٔ شبکه را باز کنید، ثبت درخواست‌ها را فعال نگه دارید و صفحهٔ نمونه را بارگذاری کنید. درخواست سند اصلی را از تصویرها و فایل‌های جانبی جدا کنید. کد وضعیت، نشانی نهایی و مسیر تغییر مسیرها را بخوانید؛ خطای یک تصویر بندانگشتی لزوماً خطای صفحهٔ مقاله نیست.
اگر با خط فرمان آشنا هستید، نمونهٔ زیر فقط یک درخواست خواندن به یک نشانی عمومی می‌فرستد و هدر پاسخ را نمایش میدهد. دامنه و مسیر نمونه را با نشانی عمومی خود جایگزین کنید؛ از نشانی پرداخت، توکن بازیابی یا پیوند خصوصی استفاده نکنید. این درخواست تغییر مسیر را دنبال نمی‌کند تا پاسخ نخست پنهان نشود و بدنه را در فایل ذخیره نمی‌کند.
curl -sS -D - -o /dev/null 'https://example.com/sample-post/'
در ویندوز، اگر دستور curl به ابزار دیگری اشاره می‌کند، از ابزار شبکهٔ مرورگر استفاده کنید یا نام اجرایی واقعی ابزار را مشخص کنید؛ گزینهٔ خروجی بالا برای محیط سازگار با این مسیر نوشته شده است. پاسخ را کنار مشاهدهٔ مرورگر تفسیر کنید، چون قواعد بعضی سامانه‌ها ممکن است براساس کوکی یا مشخصات درخواست فرق کند. پیش از ارسال خروجی برای دیگران، کوکی و هر مقدار شخصی را حذف کنید. خروجی عمومی هدر هم ممکن است جزئیاتی داشته باشد که انتشار همگانی آن لازم نیست.
وقتی فقط یک نوع محتوا یا دسته خراب است
اگر نوشته‌های معمولی سالم‌اند اما همهٔ نمونه‌های یک نوع محتوای سفارشی خراب شده‌اند، ابتدا بررسی کنید افزونه یا کدی که آن نوع را ثبت می‌کند فعال و درست بارگذاری میشود یا نه. غیرفعال‌کردن یک افزونه میتواند داده‌ها را در پایگاه داده باقی بگذارد اما مسیر نمایش آنها را از دسترس خارج کند. دیدن رکوردها بهتنهایی به معنای آماده‌بودن مسیر عمومی نیست. بازگرداندن افزونهٔ مسئول در محیط آزمایشی، از دستکاری مستقیم رکوردها معنادارتر است.
پایهٔ نشانی نوع محتوا را با برگه‌ها، دسته‌ها و قواعد زبان مقایسه کنید. دو بخش متفاوت که یک پیشوند را می‌خواهند ممکن است در اولویت تطبیق با هم برخورد کنند. برای تشخیص، چند نشانی از همان خانواده و یک مسیر کنترل از خانوادهٔ دیگر انتخاب کنید. اگر فقط آرشیو سالم است اما تک‌محتوا خراب است، گزارش را دقیقاً همین‌طور بنویسید؛ جملهٔ «افزونه کار نمی‌کند» اختلاف را پنهان می‌کند.
راه‌حل نهایی ممکن است اصلاح ثبت قواعد یا رفع تداخل نام باشد، ولی تغییر پایهٔ عمومی بدون فهرست نگاشت نشانیهای قدیم و جدید تصمیم پرهزینه‌ای از نظر نگهداری است. ابتدا امکان حفظ نشانی فعلی را بررسی کنید. در صورت ضرورت تغییر، لینک‌های منو، مسیرهای داخل متن، نقشهٔ سایت و مقصدهای خارجی مهم باید در برنامهٔ مهاجرت دیده شوند. فعال‌سازی تصادفی افزونه‌های مشابه، ثبت‌کنندهٔ مسیر را مبهم‌تر می‌کند.
زیرپوشه، دامنهٔ فرعی و نصب‌های چندگانه
در انتقال سایت، ممکن است فایل‌های وردپرس در یک پوشه باشند اما نشانی عمومی از ریشه ارائه شود. در چنین وضعی محل فایل و نشانی نمایشی را یک مفهوم فرض نکنید. راهنمای رسمی سفارشی‌سازی پیوندها انواع ساختار نشانی را توضیح میدهد؛ انتخاب ساختار خوانا هنوز به مسیریابی درست نصب وابسته است. از روی وجود پوشهٔ blog نتیجه نگیرید که همهٔ نشانی‌ها باید همان پیشوند را داشته باشند.
اگر چند نسخهٔ سایت در حساب میزبانی باقی مانده، تعیین کنید دامنه به کدام نسخه وصل است. ممکن است مدیر، پیوندهای نسخهٔ قدیمی را ذخیره کند و کاربر نسخهٔ تازه را ببیند. نام پایگاه داده یا مسیر مطلق را عمومی نکنید؛ کافی است مسئول فنی تطابق نصب و دامنه را در گزارش خصوصی تأیید کند. در دامنهٔ فرعی نیز قواعد دامنهٔ اصلی الزاماً اعمال نمی‌شوند و باید میزبان مجازی مربوط بررسی شود.
در چندسایتی، قواعد عمومی یک نصب منفرد را جایگزین قواعد شبکه نکنید. دامنه‌نگاری، پیشوند سایت‌ها و تنظیمات شبکه بر انتخاب مسیر اثر دارند. اگر فقط یکی از سایت‌های شبکه خراب است، همین محدودبودن سرنخ مهمی است. آزمایش را با یک مسیر متناظر از سایت سالم مقایسه کنید و از بازسازی هم‌زمان قواعد کل شبکه خودداری کنید؛ نتیجهٔ مورد انتظار باید برای هر دامنه جدا تعریف شود.
کش منفی و اختلاف پاسخ میان کاربران
پس از اصلاح مسیریابی، ممکن است یک لایه هنوز پاسخ ۴۰۴ قدیمی را نگه دارد. در این حالت ویرایش دوبارهٔ قواعد باعث تغییر علت دیگری نمی‌شود و فقط سابقهٔ عیب‌یابی را شلوغ می‌کند. یک نشانی مشخص را با زمان و روش درخواست ثابت بررسی کنید و در صورت دسترسی، پاسخ کش و مبدا را با همکاری میزبان مقایسه کنید. خاموش‌کردن عمومی شبکهٔ توزیع محتوا برای تشخیص یک مسیر، معمولاً دامنهٔ تغییر را بی‌جهت بزرگ می‌کند.
پاک‌سازی را از همان مسیر یا گروه مربوط آغاز کنید. اگر مسیرهای دسته و نوشته هر دو تحت تأثیرند، وابستگی آنها را در نظر بگیرید؛ پاک‌کردن فقط صفحهٔ خانه لزوماً کش سند داخلی را تغییر نمیدهد. در سایت پرترافیک، پاک‌سازی همهٔ کش‌ها میتواند بار مبدا را بالا ببرد. زمان اقدام را با مسئول سامانه هماهنگ کنید و پاسخ پس از پاک‌سازی را ثبت کنید تا مشخص باشد چه لایه‌ای اثر داشته است.
اختلاف موبایل و دسکتاپ را نیز پیش از نسبت‌دادن به قالب بسنجید. ممکن است تلفن روی شبکه‌ای دیگر یا با کش متفاوت درخواست بفرستد و اصلاً سند متفاوتی نگیرد. اگر کد سند اصلی یکسان است اما دکمهٔ منوی موبایل به مسیر قدیمی می‌رود، مسئله در لینک رابط است. آزمایش خصوصی مرورگر برای جداکردن وضعیت محلی مفید است، اما موفقیت آن بهتنهایی سلامت همهٔ کاربران را اثبات نمی‌کند.
نامک فارسی، صفحه‌بندی و مسیرهای کم‌دیده‌شده
خطاهای محدود به نشانی فارسی را با کپی مستقیم لینک تولیدشدهٔ وردپرس بررسی کنید. تفاوت ی و ک، فاصله و نیم‌فاصله میتواند دو رشتهٔ متفاوت بسازد، حتی اگر در نگاه اول شبیه باشند. نامک را برای همهٔ نوشتهها دوباره تایپ نکنید؛ ابتدا یک نمونه را در منبع لینک، نوار نشانی و خروجی پیشخوان مقایسه کنید. اگر فقط لینک یک پیام‌رسان مشکل دارد، همان مسیر انتشار لینک را اصلاح کنید.
صفحهٔ اول آرشیو ممکن است سالم باشد اما صفحه‌های بعدی خراب باشند. وجود واقعی صفحهٔ بعد، تعداد محتوای منتشرشده و تنظیمات آرشیو را کنترل کنید. گاهی صفحه‌ای که قبلاً وجود داشته پس از کم‌شدن تعداد نوشتهها دیگر منطقی نیست. این وضعیت با خرابی عمومی پیوند یکتا تفاوت دارد و نباید با ایجاد پاسخ موفق برای هر شماره پنهان شود. مسیر جست‌وجو و خوراک نیز بسته به ساختار سایت میتواند آزمون جداگانه بخواهد.
فیلتر فروشگاه یا انتخاب زبان ممکن است پارامتر یا پیشوندی به نشانی اضافه کند. اگر مسیر پایه سالم است و فقط نسخهٔ فیلترشده خطا دارد، مقدار فیلتر، افزونهٔ تولیدکننده و قواعد مربوط را بررسی کنید. حذف همهٔ پارامترها از لینک‌های سایت میتواند قابلیت کاربر را خراب کند. مسئله را با یک ترکیب حداقلی بازتولید کنید و هر بار فقط یک شرط اضافه کنید تا عامل ایجاد خطا مشخص شود.
سناریوی فرضی اول؛ انتقال سرور و خرابی تمام نوشتهها
فرض کنید سایتی پس از انتقال به زیرساخت تازه، خانه و پیشخوان سالم دارد اما همهٔ نوشته‌های منتشرشده ۴۰۴ میدهند. این مثال آموزشی است و گزارش یک آزمایش واقعی نیست. سه فرضیه مطرح میشود: محتوا منتقل نشده، قواعد وردپرس قدیمی مانده یا سرور جدید مسیرهای مجازی را به برنامه نمی‌فرستد. مدیر ابتدا دو نوشته را در پیشخوان باز می‌کند و وضعیت انتشار و متن آنها را می‌بیند؛ فرضیهٔ حذف عمومی محتوا ضعیف میشود، ولی هنوز سلامت مسیر اثبات نشده است.
پس از تهیهٔ نسخهٔ بازگشت، همان ساختار پیوند ذخیره میشود و نتیجه تغییری نمی‌کند. مدیر از روی ظاهر صفحه نمی‌گوید حتماً nginx مقصر است؛ از میزبان نوع و پیکربندی فعال را می‌پرسد. در فرض این داستان، میزبان تأیید می‌کند درخواست مسیر ناموجود فیزیکی پیش از ورودی وردپرس پایان می‌یابد. اکنون اصلاح باید در قاعدهٔ مسیریابی همان دامنه انجام شود، نه با تغییر نامک نوشتهها یا نصب افزونهٔ ریدایرکت.
معیار نتیجه این است که نوشته‌های نمونه با متن درست پاسخ موفق بدهند، تصویر واقعی همچنان تصویر باشد و مسیر ساختگی پاسخ ناموجود بماند. اگر این سه شرط برقرار نشود، اصلاح پذیرفته نیست. اگر به جای متن نوشته، خانه ظاهر شود، مقصد جایگزین اشتباه انتخاب شده است. در صورت خرابی منابع واقعی یا ایجاد خطای تازه، مدیر فقط پیکربندی اخیر را برمی‌گرداند و گزارش مسیر انتخاب‌شده را برای بررسی بعدی نگه می‌دارد.
سناریوی فرضی دوم؛ محصول حذفشده یا تداخل پایه
فروشگاهی فرضی را در نظر بگیرید که پس از مرتب‌سازی محصولات، چند لینک محصول و یک دسته خطا میدهند. این هم نمونهٔ آموزشی است. فرضیهٔ اول حذف محصولات است؛ فرضیهٔ دوم تغییر پایهٔ نشانی محصول؛ فرضیهٔ سوم تداخل یک برگهٔ تازه با همان پیشوند. مسئول محتوا برای هر لینک، شناسهٔ محصول و نشانی تولیدشدهٔ فعلی را استخراج می‌کند. مشخص میشود بخشی از محصولات واقعاً به زباله‌دان رفته‌اند، اما یک محصول منتشرشده نیز با نشانی فعلی خراب است.
دو مسئله باید جدا رسیدگی شوند. برای محصول حذفشده، مسئول فروش تصمیم می‌گیرد آیا جایگزین واقعاً هم‌ارز وجود دارد یا باید صفحهٔ نبودن محتوا حفظ شود. برای محصول موجود، در محیط آزمایشی پیشوند برگهٔ تازه و قواعد فروشگاه بررسی میشود. اگر با رفع تداخل، فقط خانوادهٔ محصول سالم شود، فرضیهٔ برخورد مسیر تقویت میشود؛ اگر تغییری نکند، باید ثبت قواعد و کش بررسی شود و نباید نتیجهٔ دلخواه را به آزمایش نسبت داد.
پذیرش نهایی شامل صفحهٔ محصول، دسته، انتخاب ویژگی و بازگشت از سبد است. خرید آزمایشی باید طبق روش امن فروشگاه و بدون دریافت وجه ناخواسته انجام شود. سفارش‌های واقعی نباید با بازگرداندن یک پشتیبان قدیمی از بین بروند. این سناریو نشان میدهد یک عبارت مشترک روی صفحه میتواند دو علت مستقل داشته باشد؛ درمان سراسری برای تمام ۴۰۴ها، هم محصول حذفشده را پنهان می‌کند و هم علت تداخل را دست‌نخورده باقی می‌گذارد.
پیامدهای ووکامرس برای سفارش و پرداخت
در فروشگاه، صفحهٔ محصول فقط یکی از مسیرهای مهم است. سبد، تسویه، حساب کاربری و برگشت درگاه می‌توانند وابستگی‌های متفاوتی داشته باشند. بررسی آنها را به بازشدن خانه تقلیل ندهید. اگر مشکل از مسیر بازگشت پرداخت گزارش شده، نشانی کامل حاوی اطلاعات سفارش را عمومی نکنید و نمونهٔ پاک‌سازی‌شده را به مسئول مجاز بدهید. تکرار درخواست واقعی پرداخت برای آزمودن قواعد، روش مناسبی برای تشخیص نیست.
پیش از تغییر زنده، مشخص کنید تراکنش باز وجود دارد یا نه و چه کسی نتیجهٔ پرداخت را با وضعیت سفارش تطبیق میدهد. محیط آزمایشی باید از ارسال ایمیل سفارش و اتصال به درگاه واقعی جدا باشد. اگر اصلاح تنها در قواعد سرور است، همان فایل را قابل بازگشت نگه دارید؛ بازیابی کل سایت برای برگشت چند خط تنظیمات میتواند وضعیت مالی تازه را ناسازگار کند. دامنهٔ بازگشت باید با دامنهٔ تغییر برابر باشد.
پس از تعمیر، یک مسیر عمومی محصول و یک جریان مجاز خرید را جداگانه تأیید کنید. سالمبودن نمایش محصول به معنای سالمبودن مقصد تأیید سفارش نیست. همچنین افزونه‌های چندزبانه یا چندارزی ممکن است نشانیهای متفاوتی بسازند؛ فقط حالت پیش‌فرض را نبینید. نتیجه را با نقش کاربر، زبان و روش ورود ثبت کنید تا خطای محدود به یک گروه، پشت عبارت کلی «فروشگاه درست شد» پنهان نماند.
۴۰۴ عمدی، ۴۱۰ و پرهیز از انتقال همگانی به خانه
هر نشانی ناموجود به تعمیر فنی نیاز ندارد. اگر محتوا عمداً حذف شده و جایگزین مرتبطی ندارد، نگه‌داشتن پاسخ ناموجود میتواند تصمیم درست باشد. برای حذف آگاهانه و دائمی، پاسخ ۴۱۰ نیز بسته به سیاست فنی سایت قابل بررسی است. این تصمیم را براساس وضعیت محتوا بگیرید، نه برای کم‌کردن ظاهری تعداد خطاها در یک گزارش. مقصدی که فقط کاربر را سرگردان می‌کند، جایگزین محتوای حذفشده نیست.
مستند گوگل دربارهٔ کدهای HTTP میان پاسخ‌های موفق و خطاهای کاربر تفاوت می‌گذارد. برای کار عملی، پیام صفحه و کد پاسخ باید هم‌خوان باشند. صفحه‌ای با عبارت «پیدا نشد» و پاسخ موفق، یا انتقال انبوه مسیرهای نامرتبط به خانه، وضعیت محتوا را مبهم می‌کند. طراحی صفحهٔ مفید خطا باید امکان جست‌وجو و مسیرهای مناسب بدهد، بدون آنکه معنای پاسخ را پنهان کند.
برای محتوای منتقلشده، فهرست نگاشت قدیم به مقصد هم‌معنا تهیه کنید. هر مقصد را پیش از ثبت قانون باز کنید و از نبود حلقه یا زنجیرهٔ بی‌دلیل مطمئن شوید. یک محصول جایگزین تنها وقتی مناسب است که نیاز کاربر را واقعاً پوشش دهد؛ شباهت دسته بهتنهایی کافی نیست. مسیرهای تصادفی و غلط‌های تایپی را با انتقال فراگیر به خانه مخفی نکنید، چون این کار تشخیص نشانیهای واقعاً شکسته را هم سخت‌تر می‌کند.
canonical، نقشهٔ سایت و لینک‌های داخلی پس از تعمیر
پس از بازشدن صفحه، نشانی نهایی را با لینک canonical و نشانی درج‌شده در نقشهٔ سایت مقایسه کنید. اگر صفحهٔ بازیابی‌شده به نشانی دیگری اشاره می‌کند، هنوز دربارهٔ نسخهٔ مرجع ابهام وجود دارد. canonical ابزار برگرداندن محتوای غایب نیست؛ ابتدا منبع باید درست پاسخ دهد. لینک منو، مسیر راهنما و پیوندهای داخل نوشتهها را به مقصد جاری اصلاح کنید تا بازدیدکننده برای رسیدن به آن مجبور به عبور از نشانی قدیمی نباشد.
اگر مهاجرت نشانی انجام شده، راهنمای رسمی گوگل دربارهٔ تغییر مسیر تفاوت انتقال دائمی و موقت را توضیح میدهد. انتخاب نوع انتقال باید با قصد واقعی جابه‌جایی سازگار باشد. از این انتخاب نمی‌توان وعدهٔ زمان ایندکس یا رشد رتبه نتیجه گرفت. پیگیری در ابزارهای جست‌وجو برای مشاهدهٔ وضعیت مفید است، ولی درخواست بررسی مجدد جای اصلاح پاسخ سرور را نمی‌گیرد.
نقشهٔ سایت را به فهرست نشانیهای معتبر و موردنظر محدود کنید. اگر ابزار تولید نقشه هنوز محصول حذفشده را نشان میدهد، علت حضور آن را در وضعیت انتشار یا تنظیمات تولیدکننده پیدا کنید. حذف دستی یک خط از خروجی موقت ممکن است با تولید بعدی برگردد. برای هماهنگی فنی و محتوایی این تصمیم‌ها، بررسی سئوی سایت باید بر وضعیت واقعی نشانی‌ها و هدف هر صفحه تکیه کند، نه صرفاً کاهش تعداد هشدارها.
آزمون پذیرش با مسیر سالم و مسیر عمداً ناموجود
فهرست پذیرش را پیش از اعلام پایان کار اجرا کنید: خانه، نوشتهٔ قدیمی، برگه، دسته، صفحهٔ بعدی آرشیو در صورت وجود و یک فایل رسانهٔ واقعی. در فروشگاه، محصول و مسیرهای حساس توافق‌شده را اضافه کنید. برای هر مورد، محتوای مورد انتظار و کد پاسخ را با هم ببینید. یک پاسخ موفق که محتوای صفحهٔ دیگری را می‌آورد مردود است، همان‌طور که متن درست با کد خطای ناخواسته هنوز نیازمند بررسی است.
مسیر ساختگی کنترل را حذف نکنید. کار آن اثبات این است که قواعد تازه همهٔ درخواست‌ها را به یک صفحهٔ موفق تبدیل نکرده‌اند. همچنین یک لینک قدیمی با مقصد مشخص را بررسی کنید تا انتقال آن مستقیم و مرتبط باشد. مسیرهایی که نباید منتقل شوند باید رفتار تعریف‌شدهٔ خود را حفظ کنند. این آزمون منفی مکمل آزمون مثبت است و از تعمیر ظاهری جلوگیری می‌کند.
بررسی را در حالت مهمان و روی یک مرورگر موبایل تکرار کنید. اگر اختلافی وجود دارد، نشانی واقعی درخواست و کد سند را مقایسه کنید؛ تعداد کلیک یا ظاهر مشابه معیار کافی نیست. زمان، عامل تغییر و نتیجه را ثبت کنید. برای مرور منظم خطاهای پیش از انتشار و جلوگیری از فراموشی این آزمون‌ها، اشتباهات راه‌اندازی سایت مسیر مرتبطی برای ادامهٔ کار است.
بازگشت هدفمند و بستهٔ تحویل به مسئول فنی
اگر بعد از تغییر، مشکل بزرگ‌تر شد، همان تغییر اخیر را به نسخهٔ ثبت‌شده برگردانید و درخواست کنترل را تکرار کنید. بازگشت زمانی معتبر است که رفتار پیش از تغییر نیز برگردد؛ صرف کپی‌کردن فایل کافی نیست، چون ممکن است کش یا پیکربندی فعال دیگری دخیل باشد. در فروشگاه، بازگشت فایل نباید با بازیابی بی‌دلیل پایگاه داده همراه شود. اگر دادهٔ تازه در معرض حذف است، تصمیم را به مسئول مجاز بازیابی بسپارید.
برای ارجاع، گزارش کوتاه اما دقیق تهیه کنید: چند نشانی عمومی نمونه، زمان آغاز، آخرین تغییر شناخته‌شده، کدهای پاسخ و نتیجهٔ ذخیرهٔ بدون تغییر پیوندها. نوع وب‌سرور را با درجهٔ اطمینان بنویسید؛ اگر فقط از یک هدر حدس زده‌اید، آن را تأیید قطعی معرفی نکنید. خروجی عمومی را از کوکی، نشانی خصوصی و اطلاعات سفارش پاک کنید. مسئول فنی باید بتواند با گزارش شما همان مسئله را بازتولید کند.
وقتی دسترسی به تنظیمات مؤثر ندارید، تغییرهای تصادفی داخل وردپرس را ادامه ندهید. از میزبان سؤال مشخص بپرسید: درخواست این مسیر در کدام لایه پایان می‌یابد و آیا به ورودی نصب درست می‌رسد؟ پاسخ این پرسش به انتخاب قدم بعدی کمک می‌کند. تحویل خوب شامل معیار پایان نیز هست؛ مثلاً نوشتهٔ مشخص با محتوای خودش باز شود و مسیر ساختگی همچنان ناموجود بماند.
اولویت‌بندی گزارش‌ها براساس منشأ لینک خراب
برای رسیدگی روزانه، کنار هر مسیر خراب بنویسید کاربر از کجا به آن رسیده است. لینکی که هنوز در منوی اصلی وجود دارد، به اقدام متفاوتی از نشانی تصادفی یک ربات نیاز دارد. اگر منبع داخل سایت است، همان صفحهٔ تولیدکنندهٔ لینک را باز کنید و مقصد را اصلاح کنید؛ ساختن انتقال بدون اصلاح لینک داخلی، وابستگی غیرضروری را نگه می‌دارد. اگر منبع یک خبرنامهٔ قدیمی است و محتوا جابه‌جا شده، نگاشت محدود به مقصد مرتبط میتواند تصمیم مناسب‌تری باشد.
نبودن اطلاعات ارجاع، دلیل بی‌ارزش‌بودن مسیر نیست. بعضی مرورگرها یا مسیرهای ورود این اطلاعات را نمی‌فرستند. وضعیت انتشار، سابقهٔ نشانی و اهمیت محتوایی را هم بررسی کنید. از سوی دیگر، تعداد زیاد درخواست برای یک مسیر ناشناس الزاماً به معنای تقاضای واقعی کاربر نیست. پیش از ایجاد صفحه یا انتقال، ببینید آیا این نشانی در قرارداد محتوایی سایت سابقه‌ای دارد یا صرفاً درخواست نامعتبر است.
نتیجهٔ هر رسیدگی را با یک تصمیم مشخص ببندید: اصلاح لینک تولیدکننده، بازیابی محتوای موجود، انتقال مرتبط یا حفظ پاسخ ناموجود. نام مسئول و شرط بازبینی را در گزارش داخلی نگه دارید. این طبقه‌بندی از آن جلوگیری می‌کند که همان مسیر در گزارش بعدی دوباره بدون زمینه بررسی شود. اگر پس از اصلاح لینک داخلی هنوز درخواست‌های قدیمی ادامه دارند، منشأ خارجی یا کش را بررسی کنید؛ برای کم‌کردن ظاهری تکرارها، تصمیم درست قبلی را بی‌دلیل عوض نکنید.
پیش از بستن گزارش، لینک اصلاح‌شده را از همان محل مصرف دوباره باز کنید. سالمبودن مقصد در نوار نشانی ثابت نمی‌کند منو یا متن مقاله واقعاً به‌روز شده است؛ ممکن است نسخهٔ کش‌شدهٔ صفحهٔ مبدأ هنوز لینک قبلی را نشان دهد. اگر تولیدکنندهٔ لینک یک ابزار خودکار است، علت تولید نشانی قدیمی را در تنظیمات همان ابزار اصلاح کنید. ثبت این تفاوت کمک می‌کند تیم بعدی بداند مشکل در مقصد بوده یا در انتشار لینک و برای مشاهدهٔ مشابه، دوباره قواعد سرور را دستکاری نکند.
جلوگیری از تکرار با مدیریت تغییر نشانی‌ها
برای هر تغییر ساختار محتوا، فهرست نشانیهای اثرپذیر را پیش از اجرا تهیه کنید. تغییر نام دسته، جابه‌جایی پایهٔ محصول یا حذف افزونهٔ ثبت‌کنندهٔ محتوا ممکن است به لینک‌های عمومی وابسته باشد. مسئول محتوا باید بداند کدام تصمیم فقط عنوان نمایشی را عوض می‌کند و کدام تصمیم قرارداد نشانی را تغییر میدهد. داشتن این تفکیک از ساختن ریدایرکت‌های اضطراری پس از هر ویرایش جلوگیری می‌کند.
پس از انتقال میزبانی یا تغییر وب‌سرور، آزمون مسیرهای داخلی را بخشی از تحویل قرار دهید. بازشدن خانه و ورود مدیر برای پذیرش انتقال کافی نیست. نمونه‌های فارسی، آرشیو، رسانه و فروشگاه را در فهرست ثابت نگه دارید و نتیجهٔ قبل و بعد را مقایسه کنید. اگر افزونه‌ای مرتب قواعد را بازنویسی می‌کند، زمان و شرط اجرای آن را بررسی کنید؛ تعمیر دستی دوره‌ای جای اصلاح رفتار آن را نمی‌گیرد.
پایش را بر نشانی و علت متمرکز کنید. افزایش خطاهای تصادفی ربات‌ها با خراب‌شدن یک لینک مهم داخلی یکسان نیست. ابتدا مسیرهای پرتکرارِ دارای منبع داخلی و صفحات منتشرشدهٔ موردنظر را بررسی کنید، سپس موارد حذف عمدی و درخواست‌های نامعتبر را جدا تفسیر کنید. با این روش گزارش خطا به فهرست کار قابل اجرا تبدیل میشود و تیم برای کم‌کردن عدد ظاهری، رفتار درست صفحات ناموجود را قربانی نمی‌کند.