راهنمای کامل رفع خطای پیوند یکتای وردپرس

خطای پیوند یکتا در وردپرس یکی از آن مشکلاتی است که به‌طور کامل سایت را از دسترس کاربران خارج می‌کند، ولی به شکلی ناآشنا: به‌جای پیام خطای واضح، همه‌ی صفحات به صفحه‌ی اصلی ریدایرکت می‌شوند، نوشته‌ها با خطای ۴۰۴ باز نمی‌شوند، آدرس‌های محصولات فروشگاه کار نمی‌کنند و کاربر در سایت شما گم می‌شود. سال‌هاست روی سایت‌های وردپرسی با این خطا مواجه می‌شوم و در تجربه‌ام، ریشه‌ی این خطا تقریباً همیشه در یکی از پنج لایه‌ی مشخص پنهان است: فایل htaccess، ماژول mod_rewrite، مجوز فایل، پیکربندی سرور یا تنظیمات دیتابیس.

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

پیوند یکتا در وردپرس دقیقاً چگونه کار می‌کند؟

پیوند یکتا یا Permalink، به آدرس نهایی هر صفحه در سایت شما اشاره دارد. توضیح تکمیلی این مفهوم در ویکی‌پدیا موجود است، ولی جان ماجرا در این نکته است که در وردپرس، پیوند یکتا از یک ساختار سه‌لایه‌ای تشکیل شده: قالب URL که مدیر سایت در تنظیمات انتخاب می‌کند، قواعد rewrite که وردپرس در دیتابیس ذخیره می‌کند، و در نهایت تبدیل قواعد به دستورات وب‌سرور در فایل .htaccess یا فایل پیکربندی Nginx.

وقتی کاربر یک آدرس مثل https://yourdomain.com/blog/my-post/ را در مرورگر وارد می‌کند، درخواست به وب‌سرور می‌رسد. وب‌سرور باید تشخیص دهد که این آدرس یک فایل واقعی نیست، بلکه باید به فایل index.php وردپرس فرستاده شود تا وردپرس محتوای مربوطه را پیدا کند. این تشخیص، بر عهده‌ی قواعد rewrite است که در فایل .htaccess (در آپاچی) یا در فایل پیکربندی (در Nginx) تعریف می‌شوند.

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

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

نکته‌ی دومی که در تجربه‌ی چندساله‌ام بسیار مهم بوده، تفاوت میان «همه‌ی صفحات ۴۰۴ می‌دهند» و «فقط بعضی صفحات ۴۰۴ می‌دهند» است. در حالت اول، ریشه در قواعد rewrite یا htaccess است که برای کل سایت اعمال می‌شود. در حالت دوم، ریشه در تنظیمات یک نوشته یا یک نوع محتوای خاص است. تفکیک این دو، اولین گام در تشخیص است. مباحث مرتبط در ساختار URL و سئو باز شده است.

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

انواع خطای پیوند یکتا و نشانه‌ی هرکدام

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

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

ده ریشه‌ی اصلی خطای پیوند یکتا

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

ریشه‌ی اول: فایل htaccess ناقص یا از بین رفته

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

ریشه‌ی دوم: غیرفعال بودن ماژول mod_rewrite

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

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

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

ریشه‌ی چهارم: مجوز فایل htaccess نادرست

اگر مجوز فایل .htaccess روی 600 یا 444 باشد، وب‌سرور نمی‌تواند آن را بخواند یا وردپرس نمی‌تواند آن را بنویسد. راه‌حل: تنظیم مجوز روی 644. مباحث مرتبط در خطای دسترسی به فایل‌ها در وردپرس باز شده است.

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

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

ریشه‌ی ششم: کش سرور و کش CDN

اگر کش سرور یا کش CDN آدرس‌های قدیمی را سرو کند، تغییرات پیوند یکتا اعمال نمی‌شوند. این سناریو در سایت‌هایی که از Cloudflare یا LiteSpeed Cache سرور استفاده می‌کنند، شایع‌تر است. راه‌حل: پاک‌سازی کش. مباحث مرتبط در بهترین افزونه‌های کش وردپرس باز شده است.

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

بعضی افزونه‌های امنیتی، فایل .htaccess را بازنویسی می‌کنند و قواعد وردپرس را از بین می‌برند. این سناریو در سایت‌هایی که از افزونه‌های امنیتی مثل Wordfence یا iThemes Security استفاده می‌کنند، شایع‌تر است. راه‌حل: بررسی محتوای فایل htaccess و مقایسه با نسخه‌ی استاندارد. مباحث مرتبط در افزونه‌های امنیتی وردپرس باز شده است.

ریشه‌ی هشتم: پیکربندی نادرست Nginx

در سرورهای Nginx، فایل .htaccess استفاده نمی‌شود و قواعد باید در فایل پیکربندی Nginx تعریف شوند. اگر این قواعد ناقص باشند، پیوندهای یکتا کار نمی‌کنند. راه‌حل: بررسی فایل پیکربندی Nginx و اضافه کردن قواعد try_files.

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

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

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

اگر ساختار پیوندهای یکتا را تغییر داده‌اید ولی ریدایرکت ۳۰۱ از آدرس‌های قدیمی به جدید تنظیم نکرده‌اید، همه‌ی لینک‌های قدیمی خطای ۴۰۴ می‌دهند. این سناریو در سایت‌هایی که ساختار URL را بدون برنامه‌ریزی تغییر می‌دهند، شایع‌تر است. راه‌حل: تنظیم ریدایرکت ۳۰۱ برای آدرس‌های قدیمی. مباحث مرتبط در افزونه‌های ریدایرکت وردپرس باز شده است.

پروتکل واکنش سریع در بحران

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

1. تعیین دامنه‌ی خطا: سریع تست کنید که آیا همه‌ی صفحات خطا می‌دهند یا فقط بعضی. اگر همه، ریشه در htaccess یا mod_rewrite است. اگر فقط بعضی، ریشه در تنظیمات خاص است.
2. بازنشانی پیوندهای یکتا: از پیشخوان، مسیر تنظیمات > پیوندهای یکتا را باز کنید و بدون تغییر ساختار، روی دکمه‌ی ذخیره تغییرات بزنید. این کار قواعد rewrite را بازسازی می‌کند.
3. بررسی فایل htaccess: از طریق FTP یا File Manager، فایل .htaccess را بررسی کنید. اگر وجود ندارد یا محتوایش ناقص است، آن را با نسخه‌ی استاندارد بازسازی کنید.
4. پاک‌سازی کش: کش مرورگر، کش افزونه و کش سرور/CDN را پاک کنید.
5. غیرفعال‌سازی موقت افزونه‌های امنیتی: اگر ریشه در افزونه‌ی امنیتی است، موقتاً آن را غیرفعال کنید و تست بگیرید.

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

تشخیص دقیق با ابزارها و کوئری‌ها

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

DevTools مرورگر

در مرورگر، ابزار DevTools را باز کنید (کلید F12) و به تب Network بروید. یک آدرس نوشته را باز کنید. سه چیز را بررسی کنید:

1. کد وضعیت پاسخ: اگر ۳۰۱ باشد و به صفحه‌ی اصلی ریدایرکت شود، ریشه در htaccess است. اگر ۴۰۴ باشد، ریشه در قواعد rewrite است.
2. سربرگ Location: اگر آدرس درخواستی به آدرس دیگری ریدایرکت می‌شود، آن آدرس را بررسی کنید.
3. پاسخ سرور: اگر پاسخ خالی یا خطا باشد، ریشه در سرور است.

در تب Console، خطاهای JavaScript مربوط به لینک‌ها را بررسی کنید. اگر لینک‌ها با AJAX کار می‌کنند و خطای JavaScript دیده می‌شود، ریشه در اسکریپت‌های قالب است. مباحث مرتبط در پیدا کردن خطاهای جاوااسکریپت در کنسول باز شده است.

کوئری‌های دیتابیس

چند کوئری می‌تواند در تشخیص کمک کند:

بررسی تنظیمات پیوند یکتا:

SELECT option_name, option_value FROM wp_options
WHERE option_name = 'permalink_structure';

بررسی قواعد rewrite:

SELECT LENGTH(option_value) as rules_size
FROM wp_options
WHERE option_name = 'rewrite_rules';

اگر مقدار rules_size صفر یا بسیار کم باشد (کمتر از ۱۰۰ بایت)، قواعد rewrite ناقص هستند.

بررسی ساختار پیوند یکتا در ووکامرس:

SELECT option_name, option_value FROM wp_options
WHERE option_name LIKE 'woocommerce_%permalinks%'
   OR option_name LIKE 'woocommerce_%permalink%';

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

لاگ سرور و لاگ PHP

اگر خطای پیوند یکتا ناشی از PHP باشد، پیام دقیق در لاگ PHP ثبت می‌شود. برای فعال‌سازی، در wp-config.php مقادیر WP_DEBUG و WP_DEBUG_LOG را تنظیم کنید. لاگ در wp-content/debug.log ذخیره می‌شود. روش دقیق خواندن لاگ در بررسی خطاهای سرور در لاگ‌ها باز شده است.

فایل htaccess و ساختار استاندارد

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

ساختار استاندارد 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

برای بازنشانی فایل htaccess، سه راه‌حل:

1. از پیشخوان وردپرس: در مسیر تنظیمات > پیوندهای یکتا، بدون تغییر ساختار، روی ذخیره بزنید. وردپرس به‌طور خودکار فایل htaccess را بازنشانی می‌کند.
2. از FTP: فایل htaccess را حذف کنید و از پیشخوان، پیوندهای یکتا را ذخیره کنید تا فایل جدید ساخته شود.
3. دستی: محتوای استاندارد بالا را در فایل htaccess جایگزین کنید.

مشکل خاص: قواعد افزونه‌های امنیتی

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

مشکل خاص: htaccess در زیرپوشه

اگر وردپرس در زیرپوشه‌ای نصب شده باشد (مثل /blog/)، ساختار htaccess متفاوت است و باید RewriteBase /blog/ باشد. راه‌حل: بررسی مسیر نصب و اصلاح RewriteBase.

ماژول mod_rewrite و فعال‌سازی

ماژول mod_rewrite در آپاچی، مسئول اجرای قواعد rewrite است. اگر این ماژول فعال نباشد، قواعد htaccess نادیده گرفته می‌شوند:

بررسی فعال بودن mod_rewrite

برای بررسی فعال بودن این ماژول، دو راه:

1. از طریق SSH: با دستور apache2ctl -M | grep rewrite یا httpd -M | grep rewrite بررسی کنید.
2. از طریق phpinfo: یک فایل phpinfo موقت بسازید و بخش Apache Modules را بررسی کنید.

فعال‌سازی mod_rewrite

در سرورهای لینوکسی، برای فعال‌سازی:

sudo a2enmod rewrite
sudo systemctl restart apache2

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

مشکل خاص: AllowOverride None

در پیکربندی آپاچی، اگر مقدار AllowOverride روی None باشد، وب‌سرور فایل htaccess را نادیده می‌گیرد. این سناریو در سرورهای با پیکربندی امنیتی سختگیرانه شایع‌تر است. راه‌حل: درخواست از پشتیبانی هاست برای تغییر مقدار به All یا FileInfo.

مشکل خاص: فایل htaccess غیرقابل خواندن

اگر مجوز فایل htaccess نادرست باشد، وب‌سرور نمی‌تواند آن را بخواند. راه‌حل: تنظیم مجوز 644:

chmod 644 .htaccess

پیکربندی پیوند یکتا در Nginx

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

پیکربندی استاندارد وردپرس در Nginx

server {
    listen 80;
    server_name yourdomain.com;
    root /var/www/wordpress;
    index index.php index.html;
    
    location / {
        try_files $uri $uri/ /index.php?$args;
    }
    
    location ~ .php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
    }
    
    location ~ /.ht {
        deny all;
    }
}

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

مشکل خاص: try_files ناقص

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

مشکل خاص: rewrite اضافی در Nginx

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

مجوز فایل و مالکیت

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

مجوز صحیح فایل htaccess

فایل .htaccess باید مجوز 644 داشته باشد. اگر مجوز روی 600 باشد، وب‌سرور نمی‌تواند آن را بخواند. اگر مجوز روی 666 یا 777 باشد، سطح امنیتی سایت پایین می‌آید و بعضی سرورها فایل را نادیده می‌گیرند:

chmod 644 .htaccess

مالکیت فایل htaccess

مالکیت فایل htaccess باید با کاربر هاست هماهنگ باشد. اگر مالک فایل root باشد و وب‌سرور با کاربر دیگری اجرا شود، دسترسی به فایل با مشکل مواجه می‌شود:

chown username:username .htaccess

مشکل خاص: مجوز پوشه‌ی ریشه

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

دیتابیس و جدول wp_options

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

تنظیمات پیوند یکتا در wp_options

وردپرس تنظیمات پیوند یکتا را در ردیف‌های زیر ذخیره می‌کند:

• permalink_structure: ساختار پیوند یکتا
• rewrite_rules: قواعد rewrite
• category_base: پیشوند دسته‌بندی
• tag_base: پیشوند برچسب

پاک‌سازی و بازنشانی قواعد rewrite

برای بازنشانی قواعد rewrite در دیتابیس:

DELETE FROM wp_options WHERE option_name = 'rewrite_rules';

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

مشکل خاص: ردیف permalink_structure خالی

اگر ردیف permalink_structure خالی باشد، وردپرس از پیوندهای یکتای ساده (با ?p=123) استفاده می‌کند. اگر این ردیف به‌درستی تنظیم نشده باشد، ساختار پیوند به‌درستی اعمال نمی‌شود. راه‌حل: تنظیم مقدار مناسب:

UPDATE wp_options SET option_value = '/%postname%/'
WHERE option_name = 'permalink_structure';

قبل از اجرای این کوئری، بکاپ دیتابیس بگیرید. مباحث مرتبط در تأثیر دیتابیس بر سرعت سایت باز شده است.

مشکل خاص: حجم جدول wp_options

ردیف rewrite_rules می‌تواند در سایت‌های بزرگ حجم زیادی داشته باشد و باعث کندی کوئری‌ها شود. راه‌حل: بررسی حجم و در صورت لزوم بهینه‌سازی.

مهاجرت هاست و شکستن لینک‌ها

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

مشکل خاص: انتقال ناقص htaccess

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

مشکل خاص: تغییر ساختار URL

در بعضی مهاجرت‌ها، ساختار URL سایت تغییر می‌کند (مثلاً از دامنه‌ی قدیمی به دامنه‌ی جدید). در این حالت، همه‌ی لینک‌های داخلی و خارجی به آدرس‌های قدیمی خطای ۴۰۴ می‌دهند. راه‌حل: تنظیم ریدایرکت ۳۰۱ از دامنه‌ی قدیمی به دامنه‌ی جدید:

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

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

اگر سرور قدیمی Apache بود و سرور جدید Nginx، قواعد htaccess کار نمی‌کنند و باید به پیکربندی Nginx منتقل شوند. راه‌حل: بررسی نوع سرور جدید و پیکربندی مجدد.

مباحث مرتبط با مهاجرت در مهاجرت دیتابیس وردپرس به سرور جدید باز شده است.

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

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

ساختار پیوند یکتا در ووکامرس

در ووکامرس، پیوندهای یکتا شامل ساختار اختصاصی هستند:

• محصولات: /product/product-name/
• دسته‌بندی محصولات: /product-category/category-name/
• برچسب محصولات: /product-tag/tag-name/

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

اگر ساختار پیوند یکتا در ووکامرس به‌درستی ذخیره نشود یا اگر با تنظیمات وردپرس تضاد داشته باشد، صفحات محصول خطای ۴۰۴ می‌دهند. راه‌حل: بازنشانی پیوندهای یکتا از مسیر ووکامرس > تنظیمات > محصولات > پیوندهای یکتا و سپس بازنشانی پیوندهای یکتا از پیشخوان.

مشکل خاص: صفحات محصول با ۴۰۴

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

مشکل خاص: پیوند یکتا و محصولات متغیر

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

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

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

1. بازنشانی پیوندهای یکتا: اگر ریشه در قواعد rewrite است، از مسیر تنظیمات > پیوندهای یکتا و بدون تغییر، روی ذخیره بزنید.
2. بازسازی فایل htaccess: اگر ریشه در htaccess است، فایل را با نسخه‌ی استاندارد بازسازی کنید.
3. پاک‌سازی کش: کش مرورگر، کش افزونه و کش سرور/CDN را پاک کنید.
4. غیرفعال‌سازی افزونه‌ی مقصر: اگر ریشه در افزونه‌ی امنیتی است، موقتاً غیرفعال کنید و تست بگیرید.
5. بررسی مجوز فایل: اگر ریشه در مجوز است، مجوز فایل htaccess و پوشه‌ی ریشه را اصلاح کنید.
6. بررسی پیکربندی سرور: اگر ریشه در پیکربندی سرور است، از پشتیبانی هاست درخواست فعال‌سازی mod_rewrite یا تغییر AllowOverride کنید.

پایش مستمر و پیشگیری

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

سطح اول: پایش دوره‌ای پیوندها

هفته‌ای یک‌بار، چند آدرس از سایت خود را در مرورگر باز کنید (صفحه‌ی اصلی، یک نوشته، یک برگه، یک محصول). اگر خطای ۴۰۴ یا ریدایرکت غیرمنتظره دیدید، بلافاصله ریشه را پیدا کنید.

سطح دوم: پایش خودکار با ابزارها

ابزارهایی مثل Screaming Frog یا Google Search Console می‌توانند خطاهای ۴۰۴ و ریدایرکت‌ها را به‌طور خودکار شناسایی کنند. این ابزارها برای سایت‌های بزرگ با محتوای زیاد مفید هستند.

سطح سوم: پایش لاگ سرور

لاگ وب‌سرور را هفتگی بررسی کنید. اگر خطاهای ۴۰۴ یا ریدایرکت‌های غیرمنتظره دیده می‌شود، ریشه را قبل از بحران پیدا کنید. مباحث مرتبط در بررسی خطاهای سرور در لاگ‌ها باز شده است.

سطح چهارم: پشتیبان‌گیری از فایل htaccess

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

سطح پنجم: بکاپ منظم قبل از تغییرات

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

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

چرا همه‌ی صفحات سایت من به صفحه‌ی اصلی ریدایرکت می‌شوند؟

این الگو معمولاً به‌دلیل ناقص بودن فایل htaccess یا غیرفعال بودن mod_rewrite است. راه‌حل: بازنشانی فایل htaccess و بررسی فعال بودن mod_rewrite در سرور.

آیا افزونه‌های امنیتی می‌توانند باعث خطای پیوند یکتا شوند؟

بله، و این یکی از شایع‌ترین دلایل است. افزونه‌های امنیتی مثل Wordfence یا iThemes Security، فایل htaccess را بازنویسی می‌کنند و ممکن است بخش وردپرس را از بین ببرند. راه‌حل: بررسی دقیق محتوای فایل htaccess و اطمینان از حضور بخش # BEGIN WordPress. مباحث مرتبط در افزونه‌های امنیتی وردپرس باز شده است.

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

این الگو معمولاً به‌دلیل مجوز فایل htaccess است. اگر این فایل مجوز 644 نداشته باشد، وردپرس نمی‌تواند آن را بنویسد. راه‌حل: تنظیم مجوز 644 و بررسی مالکیت فایل.

چرا بعد از مهاجرت هاست، همه‌ی لینک‌ها شکسته‌اند؟

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

چرا فقط صفحات محصول ووکامرس خطا می‌دهند؟

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

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

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

چطور فایل htaccess را بازنشانی کنم؟

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

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

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

آیا Nginx از فایل htaccess استفاده می‌کند؟

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

چطور بفهمم سرور من Apache است یا Nginx؟

در DevTools مرورگر، سربرگ Server در پاسخ HTTP را بررسی کنید. اگر مقدار Apache یا nginx باشد، نوع سرور مشخص می‌شود. همچنین می‌توانید از ابزارهایی مثل What's My Server استفاده کنید.

چرا خطای پیوند یکتا فقط در بعضی نوشته‌ها رخ می‌دهد؟

این الگو معمولاً به‌دلیل ساختار اختصاصی یک نوع محتوا (مثل taxonomy یا custom post type) است. اگر این ساختار به‌درستی تنظیم نشده باشد، فقط صفحات همان نوع خطا می‌دهند. راه‌حل: بررسی تنظیمات آن نوع محتوا و بازنشانی پیوندهای یکتا.

آیا استفاده از ویجت در سایدبار می‌تواند خطای پیوند یکتا ایجاد کند؟

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

نکته‌های میدانی از رفع خطای پیوند یکتا

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

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

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

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

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

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