ریدایرکت HTTP به HTTPS در وردپرس چیست?

وقتی یک سایت با پروتکل HTTPS راه‌اندازی می‌شود، نسخه امن آدرس آن به‌جای http://example.com با https://example.com در دسترس قرار می‌گیرد. اما نصب گواهی SSL به‌تنهایی تضمین نمی‌کند که تمام کاربران و موتورهای جستجو به نسخه HTTPS هدایت شوند.

برای انتقال صحیح سایت وردپرسی، باید درخواست‌هایی که با HTTP وارد می‌شوند به نسخه HTTPS همان صفحه منتقل شوند. این کار معمولاً با ریدایرکت 301 انجام می‌شود؛ یعنی مرورگر و موتور جستجو متوجه می‌شوند که آدرس صفحه به‌صورت دائمی تغییر کرده است.

برای مثال، آدرس زیر:

http://example.com/about

باید مستقیماً به آدرس زیر منتقل شود:

https://example.com/about

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

ریدایرکت HTTP به HTTPS چیست و چرا اهمیت دارد؟

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

ریدایرکت صحیح سه هدف اصلی دارد:

• هدایت کاربران از آدرس قدیمی به نسخه امن صفحه
• یکپارچه کردن URLهای HTTP و HTTPS
• کمک به موتورهای جستجو برای شناسایی نسخه ترجیحی صفحات

گوگل HTTPS را برای URLهای معادل ترجیح می‌دهد؛ بااین‌حال، بهتر است فقط به انتخاب خودکار گوگل تکیه نکنید. ریدایرکت درست، لینک‌های داخلی، تگ canonical و Sitemap باید با نسخه HTTPS هماهنگ باشند. برای آشنایی بیشتر با مفهوم انتقال URL، مقاله ریدایرکت را نیز بخوانید.

قبل از ریدایرکت HTTP به HTTPS چه کارهایی انجام دهیم؟

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

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

• نصب و بررسی گواهی SSL/TLS
• باز کردن چند صفحه مهم با HTTPS
• تغییر آدرس وردپرس در صورت نیاز
• تنظیم ریدایرکت 301 در یک لایه مشخص
• بررسی منابع، لینک‌های داخلی و تنظیمات سئو
• آزمایش URLهای HTTP و HTTPS و کنترل خطاها

SSL چیست و چه ارتباطی با HTTPS دارد؟

HTTPS نسخه امن HTTP است که با استفاده از TLS، ارتباط میان مرورگر و سرور را رمزنگاری می‌کند. اصطلاح SSL هنوز به‌طور رایج استفاده می‌شود، اما در وب امروزی معمولاً TLS مسئول برقراری اتصال امن است.

به زبان ساده، گواهی SSL/TLS امکان برقراری اتصال HTTPS را فراهم می‌کند؛ اما ریدایرکت، وظیفه انتقال درخواست‌های HTTP به آدرس HTTPS را بر عهده دارد. این دو کار مرتبط‌اند، ولی یکسان نیستند.

برای فعال‌سازی گواهی می‌توانید ابتدا امکانات هاست خود را بررسی کنید. بسیاری از شرکت‌های میزبانی امکان نصب گواهی رایگان مانند Let’s Encrypt را فراهم می‌کنند. اگر درباره مفهوم گواهی و کاربرد آن سؤال دارید، مقاله SSL چیست؟ را مطالعه کنید.

مرحله اول: بررسی عملکرد HTTPS

پس از نصب گواهی، آدرس سایت را با HTTPS باز کنید؛ برای مثال:

https://example.com

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

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

مرحله دوم: تغییر آدرس سایت در وردپرس

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

تنظیمات ← عمومی

در این بخش دو گزینه مهم وجود دارد:

• نشانی وردپرس (WordPress Address): آدرس محل نصب فایل‌های اصلی وردپرس
• نشانی سایت (Site Address): آدرسی که کاربران برای مشاهده سایت استفاده می‌کنند

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

http://example.com

به:

https://example.com

توجه کنید که انتخاب نسخه دارای www یا بدون www به ساختار دامنه و URL ترجیحی سایت شما بستگی دارد. مهم این است که یک نسخه نهایی مشخص داشته باشید و سایر نسخه‌ها به همان آدرس منتقل شوند.

اگر پس از تغییر آدرس، پیشخوان وردپرس باز نشد چه کنیم؟

در صورت تنظیم اشتباه آدرس‌ها ممکن است دسترسی به پیشخوان مختل شود. در این شرایط، بسته به وضعیت سایت می‌توان مقادیر home و siteurl را از طریق دیتابیس یا تنظیمات wp-config.php اصلاح کرد. پیش از هر تغییری، از دیتابیس نسخه پشتیبان داشته باشید و اگر از روش کار مطمئن نیستید، از پشتیبانی هاست یا متخصص وردپرس کمک بگیرید.

مرحله سوم: ریدایرکت 301 از HTTP به HTTPS

تغییر آدرس در تنظیمات وردپرس به‌تنهایی تضمین نمی‌کند که همه درخواست‌های HTTP به نسخه امن منتقل شوند. باید در سطح سرور یا یکی از لایه‌های مناسب سایت، ریدایرکت را تنظیم کنید.

برای نمونه، اگر کاربر این آدرس را باز کند:

http://example.com/blog/article

مقصد باید نسخه HTTPS همان صفحه باشد:

https://example.com/blog/article

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

روش اول: ریدایرکت HTTP به HTTPS با فایل .htaccess

اگر سایت شما روی سرور Apache قرار دارد و امکان استفاده از mod_rewrite فراهم است، می‌توانید ریدایرکت را از طریق فایل .htaccess انجام دهید.

یک نمونه رایج برای انتقال درخواست‌های HTTP به HTTPS چنین است:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

این قانون در شرایط معمول Apache بررسی می‌کند که درخواست از طریق HTTPS دریافت نشده باشد و سپس همان میزبان و مسیر را با HTTPS فراخوانی می‌کند. پارامترهای Query String نیز معمولاً حفظ می‌شوند.

مهم: این کد برای همه زیرساخت‌ها مناسب نیست. اگر سایت پشت CDN یا Reverse Proxy قرار دارد، ممکن است سرور اصلی اتصال را HTTP تشخیص دهد، حتی اگر کاربر با HTTPS به CDN متصل شده باشد. در چنین شرایطی، استفاده بدون بررسی از این قانون می‌تواند حلقه ریدایرکت ایجاد کند.

کد را کجا قرار دهیم؟

در بسیاری از نصب‌های وردپرس روی Apache، فایل .htaccess در ریشه نصب وردپرس قرار دارد. برای ویرایش آن می‌توانید از File Manager هاست یا اتصال FTP استفاده کنید.

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

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

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

اگر به پیکربندی اصلی وب‌سرور دسترسی دارید، معمولاً بهتر است ریدایرکت در همان لایه انجام شود؛ زیرا درخواست قبل از اجرای کامل وردپرس منتقل می‌شود. مستندات Apache نیز برای انتقال دائمی، استفاده از دستور Redirect permanent در Virtual Host مربوط به HTTP را به‌عنوان روشی مناسب معرفی می‌کند.

روش پیاده‌سازی به نوع وب‌سرور بستگی دارد:

• Apache: تنظیمات Virtual Host یا فایل .htaccess
• Nginx: تنظیمات مربوط به سرور و بلوک درخواست‌های HTTP
• LiteSpeed: تنظیمات سازگار با ساختار وب‌سرور و قوانین سایت
• CDN یا Reverse Proxy: بررسی ریدایرکت و تنظیمات SSL/TLS در لایه واسط و سرور اصلی

اگر از نوع سرور خود مطمئن نیستید، پیش از افزودن کد از پشتیبانی هاست سؤال کنید. قانون مخصوص Apache را نباید بدون بررسی در پیکربندی Nginx یا سایر زیرساخت‌ها قرار داد. اگر سایت شما از CDN استفاده می‌کند، تنظیمات آن نیز باید با روش ریدایرکت هماهنگ باشد.

روش سوم: استفاده از افزونه برای ریدایرکت HTTPS در وردپرس

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

برای ریدایرکت ساده HTTP به HTTPS، معمولاً نیازی به نصب چند افزونه مختلف نیست. اگر سرور، افزونه امنیتی و افزونه ریدایرکت هم‌زمان قوانین متناقض اجرا کنند، احتمال ایجاد Redirect Chain یا Redirect Loop افزایش می‌یابد.

آیا افزونه Really Simple Security برای HTTPS مناسب است؟

افزونه Really Simple Security و ابزارهای مشابه می‌توانند برای مدیریت برخی تنظیمات و مشکلات مرتبط با HTTPS مفید باشند؛ اما انتخاب آن‌ها باید با توجه به تنظیمات سرور و نیاز سایت انجام شود. اگر SSL روی سرور درست نصب نشده باشد، نصب افزونه به‌تنهایی مشکل گواهی را برطرف نمی‌کند.

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

Mixed Content چیست و چرا بعد از فعال کردن HTTPS رخ می‌دهد؟

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

برای مثال، صفحه اصلی سایت با این آدرس باز می‌شود:

https://example.com/article

اما تصویر داخل صفحه از آدرس زیر بارگذاری می‌شود:

http://example.com/image.jpg

در این حالت ممکن است مرورگر بعضی منابع را مسدود کند یا هشدار امنیتی نمایش دهد. Mixed Content می‌تواند مربوط به تصاویر، فایل‌های CSS و JavaScript، فونت‌ها، iframeها، فایل‌های صوتی و ویدیویی یا منابع خارجی باشد.

چگونه Mixed Content را در وردپرس برطرف کنیم؟

صفحه‌ای را که مشکل دارد در مرورگر باز کنید و ابزار Developer Tools را اجرا کنید. در مرورگرهایی مانند Chrome می‌توانید با کلیک راست روی صفحه و انتخاب Inspect، وارد بخش Console شوید. پیام‌های Mixed Content معمولاً منبعی را که با HTTP درخواست شده است مشخص می‌کنند.

پس از شناسایی منبع، این موارد را بررسی کنید:

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

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

آیا باید URLهای HTTP را در دیتابیس وردپرس تغییر دهیم؟

اگر تعداد زیادی URL قدیمی HTTP در دیتابیس وجود دارد، ممکن است لازم باشد آن‌ها را به نسخه HTTPS تغییر دهید؛ اما این کار باید با دقت انجام شود. اجرای یک Query ساده و گسترده روی دیتابیس می‌تواند به داده‌هایی که با ساختار خاص یا به شکل serialized data ذخیره شده‌اند آسیب بزند.

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

ریدایرکت HTTP به HTTPS چه تأثیری بر سئو دارد؟

تغییر HTTP به HTTPS از نظر گوگل نوعی انتقال سایت با تغییر URL محسوب می‌شود. اجرای درست ریدایرکت به موتور جستجو کمک می‌کند نسخه قدیمی را به نسخه جدید مرتبط کند؛ اما به‌تنهایی تضمین‌کننده افزایش رتبه نیست.

برای انتقال صحیح، این موارد را بررسی کنید:

• هر URL قدیمی به نسخه HTTPS متناظر خود منتقل شود.
• تگ‌های canonical به URLهای نهایی HTTPS اشاره کنند.
• Sitemap شامل URLهای HTTPS باشد.
• لینک‌های داخلی مستقیماً به نسخه HTTPS اشاره کنند.
• از ایجاد زنجیره و حلقه ریدایرکت جلوگیری شود.
• صفحات مهم از نظر Crawl و Indexing بررسی شوند.

اگر می‌خواهید با نقش این انتقال در بهینه‌سازی سایت بیشتر آشنا شوید، مقاله سئو را مطالعه کنید. همچنین، هماهنگ بودن نسخه نهایی URL با تگ canonical اهمیت دارد.

آیا باید Sitemap را بعد از انتقال به HTTPS تغییر دهیم؟

بله. اگر Sitemap سایت شامل URLهای HTTP است، باید آن را بررسی کنید و نسخه HTTPS صفحات قابل ایندکس را در آن قرار دهید.

برای مثال، آدرس زیر در Sitemap نسخه قدیمی است:

http://example.com/page/

نسخه موردنظر باید با HTTPS و مطابق URL نهایی سایت باشد:

https://example.com/page/

پس از اصلاح Sitemap، آن را در Google Search Console بررسی و در صورت نیاز مجدداً معرفی کنید. ارسال Sitemap به گوگل به معنی ایندکس فوری همه URLها نیست؛ وضعیت صفحات را در گزارش‌های مربوطه نیز پایش کنید.

آیا باید Canonical را هم از HTTP به HTTPS تغییر دهیم؟

بله. اگر نسخه ترجیحی سایت HTTPS است، تگ canonical صفحات نیز باید به URL نهایی HTTPS اشاره کند. باقی ماندن canonical روی HTTP می‌تواند سیگنال متناقضی درباره نسخه اصلی صفحه ایجاد کند.

برای مثال، اگر صفحه اصلی موردنظر این آدرس است:

https://example.com/article

canonical نباید همچنان به نسخه HTTP همان صفحه اشاره کند. علاوه بر canonical، آدرس‌های موجود در Sitemap و لینک‌های داخلی را هم با URL نهایی هماهنگ کنید.

آیا لینک‌های داخلی را هم باید اصلاح کنیم؟

بله. بهتر است لینک‌های داخلی سایت مستقیماً به نسخه HTTPS صفحات مقصد اشاره کنند تا درخواست‌های غیرضروری به آدرس‌های قدیمی ایجاد نشود.

برای مثال، اگر در یک مقاله لینک زیر قرار دارد:

http://example.com/services/

بهتر است آن را به آدرس نهایی HTTPS تغییر دهید. این موضوع برای لینک‌های داخلی، منوها، دکمه‌ها، تصاویر و لینک‌های قرارگرفته در قالب نیز اهمیت دارد.

Redirect Chain چیست؟

Redirect Chain زمانی ایجاد می‌شود که برای رسیدن به URL نهایی، چند ریدایرکت پشت سر هم اجرا شود. برای مثال، کاربر ابتدا از HTTP به نسخه دارای www منتقل شود و سپس به دلیل تنظیمات دیگر به نسخه بدون www برود.

بهتر است درخواست HTTP مستقیماً به نسخه نهایی HTTPS منتقل شود؛ برای نمونه:

http://example.com/page

مستقیماً به:

https://example.com/page

اگر هم‌زمان قصد دارید www را حذف یا اضافه کنید یا ساختار دیگری از URL را تغییر دهید، قوانین را طوری تنظیم کنید که کاربر در نهایت با کمترین تعداد انتقال به آدرس ترجیحی برسد.

Redirect Loop چیست؟

Redirect Loop زمانی رخ می‌دهد که سایت درخواست را پی‌درپی بین دو یا چند آدرس منتقل کند و مرورگر نتواند به صفحه نهایی برسد. یکی از حالت‌های رایج آن، رفت‌وبرگشت مداوم بین HTTP و HTTPS است.

این مشکل ممکن است زمانی رخ دهد که وردپرس درخواست را HTTP تشخیص دهد و آن را به HTTPS منتقل کند، اما تنظیمات سرور یا Proxy باعث شود درخواست دوباره به شکل HTTP پردازش شود. در این وضعیت، افزودن قانون‌های بیشتر بدون تشخیص علت اصلی می‌تواند مشکل را تشدید کند.

اگر سایت پشت Cloudflare یا Reverse Proxy باشد چه کنیم؟

اگر اتصال HTTPS در لایه CDN یا Reverse Proxy برقرار می‌شود، باید تنظیمات ارتباط میان آن لایه و سرور اصلی را بررسی کنید. ممکن است کاربر با HTTPS متصل شود، اما ارتباط داخلی تا سرور با HTTP برقرار باشد. اگر سرور اصلی پروتکل واقعی درخواست را درست تشخیص ندهد، ریدایرکت تکراری ایجاد می‌شود.

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

چگونه خطای Too Many Redirects را برطرف کنیم؟

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

• آدرس‌های وردپرس: بررسی کنید WordPress Address و Site Address با نسخه نهایی HTTPS هماهنگ باشند.
• فایل .htaccess: قانون‌های تکراری یا متناقض را بررسی کنید و قبل از تغییر از فایل نسخه پشتیبان داشته باشید.
• افزونه‌ها: بررسی کنید چند افزونه هم‌زمان ریدایرکت یا HTTPS را مدیریت نکنند.
• CDN و Proxy: تنظیمات SSL/TLS و تشخیص پروتکل در سرور اصلی را بررسی کنید.
• کش: کش مرورگر، افزونه، سرور و CDN را در صورت نیاز پاک کنید و دوباره آزمایش کنید.

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

آیا می‌توان با wp-config.php استفاده از HTTPS را اجباری کرد؟

وردپرس تنظیمی به نام FORCE_SSL_ADMIN دارد که برای استفاده از HTTPS در بخش مدیریت و ورود کاربران کاربرد دارد. نمونه تنظیم آن در فایل wp-config.php چنین است:

define( 'FORCE_SSL_ADMIN', true );

این تنظیم با ریدایرکت کامل HTTP به HTTPS یکسان نیست. برای انتقال همه URLهای عمومی سایت، باید ریدایرکت در لایه مناسب سرور یا زیرساخت سایت تنظیم شود. همچنین پیش از فعال کردن این گزینه، از عملکرد صحیح HTTPS و تشخیص درست پروتکل در سرور مطمئن شوید.

آیا HSTS همان ریدایرکت HTTPS است؟

خیر. HSTS یا HTTP Strict Transport Security مکانیزمی است که به مرورگر اعلام می‌کند برای دامنه موردنظر از HTTPS استفاده کند. این قابلیت با ریدایرکت 301 تفاوت دارد.

در ریدایرکت 301، سرور درخواست HTTP را دریافت می‌کند و پاسخ انتقال به URL جدید را می‌فرستد. اما HSTS به مرورگر می‌گوید در درخواست‌های بعدی، از اتصال امن استفاده کند.

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

چطور مطمئن شویم ریدایرکت HTTP به HTTPS درست کار می‌کند؟

پس از تنظیم ریدایرکت، چند URL مهم را با مرورگر یا ابزار بررسی HTTP Status آزمایش کنید. نتیجه مورد انتظار این است که URL قدیمی HTTP با وضعیت 301 به URL نهایی HTTPS منتقل شود و صفحه مقصد پاسخ مناسب، معمولاً 200 OK، ارائه کند.

برای نمونه، ساختار صحیح چنین است:

http://example.com/page
        ↓ 301
https://example.com/page
        ↓ 200 OK

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

بعد از انتقال به HTTPS در Google Search Console چه کنیم؟

پس از انتقال، وضعیت صفحات HTTPS را در Google Search Console بررسی کنید. به‌ویژه این موارد اهمیت دارند:

• بررسی وضعیت ایندکس صفحات مهم
• کنترل Sitemap و URLهای درج‌شده در آن
• استفاده از URL Inspection برای بررسی صفحات مهم
• بررسی خطاهای Crawl و مشکلات دسترسی
• پایش کلیک‌ها، نمایش‌ها و وضعیت صفحات پس از انتقال

اگر نسخه‌های مختلف دامنه در Search Console ثبت شده‌اند، گزارش‌ها را با توجه به ساختار ثبت‌شده بررسی کنید. پس از انتقال، تغییر وضعیت ایندکس و نمایش URLهای HTTPS ممکن است زمان‌بر باشد؛ بنابراین به‌جای انتظار برای تغییر فوری همه صفحات، گزارش‌ها را به‌صورت دوره‌ای پایش کنید.

آیا انتقال وردپرس از HTTP به HTTPS باعث افت رتبه می‌شود؟

انتقال صحیح به HTTPS نباید به‌خودی‌خود باعث افت دائمی رتبه شود؛ اما اجرای اشتباه آن می‌تواند مشکلات فنی و سئویی ایجاد کند. برای مثال، انتقال صفحات به مقصد نامرتبط، باقی ماندن canonicalهای HTTP، Sitemap قدیمی، ایجاد زنجیره ریدایرکت یا در دسترس نبودن صفحات مهم ممکن است بر Crawl و Indexing تأثیر بگذارد.

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

اشتباهات رایج در ریدایرکت HTTP به HTTPS

• نصب SSL بدون تنظیم ریدایرکت: فعال شدن HTTPS لزوماً به معنی انتقال خودکار همه درخواست‌های HTTP نیست.
• انتقال همه صفحات به صفحه اصلی: هر URL باید تا حد امکان به نسخه HTTPS متناظر خودش منتقل شود.
• اجرای چند قانون ریدایرکت: تنظیمات متناقض سرور، CDN و افزونه‌ها ممکن است حلقه ریدایرکت ایجاد کنند.
• نادیده گرفتن Mixed Content: منابع HTTP باقی‌مانده ممکن است باعث هشدار یا بارگذاری ناقص شوند.
• فراموش کردن canonical و Sitemap: این بخش‌ها باید با URLهای نهایی HTTPS هماهنگ باشند.
• تغییر مستقیم دیتابیس بدون پشتیبان: جایگزینی گسترده URLها بدون توجه به ساختار داده‌های وردپرس خطرناک است.
• فعال کردن زودهنگام HSTS: ابتدا باید از عملکرد کامل HTTPS اطمینان حاصل کنید.

چک‌لیست انتقال وردپرس از HTTP به HTTPS

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

• گواهی SSL/TLS معتبر و فعال است.
• صفحات مهم با HTTPS بدون هشدار باز می‌شوند.
• WordPress Address و Site Address با نسخه نهایی هماهنگ‌اند.
• درخواست‌های HTTP با ریدایرکت 301 منتقل می‌شوند.
• مسیر صفحات در مقصد حفظ شده است.
• Redirect Chain و Redirect Loop وجود ندارد.
• Mixed Content بررسی و اصلاح شده است.
• لینک‌های داخلی به HTTPS اشاره می‌کنند.
• canonical صفحات به URLهای نهایی اشاره می‌کند.
• Sitemap شامل URLهای HTTPS است.
• فرم‌ها، تصاویر، فایل‌ها و بخش ورود کاربران کار می‌کنند.
• وضعیت صفحات مهم در Google Search Console بررسی شده است.
• کش سایت و CDN در صورت نیاز پاک‌سازی و دوباره آزمایش شده‌اند.

بهترین روش ریدایرکت HTTP به HTTPS در وردپرس چیست؟

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

• از فایل‌ها و دیتابیس نسخه پشتیبان بگیرید.
• SSL را نصب و عملکرد HTTPS را آزمایش کنید.
• آدرس‌های وردپرس را با نسخه نهایی HTTPS هماهنگ کنید.
• در یک لایه مشخص و متناسب با سرور، ریدایرکت 301 را تنظیم کنید.
• منابع HTTP باقی‌مانده، لینک‌های داخلی و دیتابیس را در صورت نیاز بررسی کنید.
• canonical و Sitemap را اصلاح کنید.
• URLهای مهم را از نظر کد وضعیت، مقصد نهایی و عملکرد صفحه آزمایش کنید.
• وضعیت Crawl و Indexing را پس از انتقال پایش کنید.

برای سرور Apache، تنظیم در سطح وب‌سرور معمولاً انتخاب مناسبی است و در صورت نداشتن دسترسی به پیکربندی اصلی می‌توان از .htaccess استفاده کرد. در سایت‌های مبتنی بر Nginx، CDN یا Reverse Proxy باید روش متناسب با همان زیرساخت انتخاب شود.

جمع‌بندی

ریدایرکت HTTP به HTTPS در وردپرس فقط تغییر پروتکل آدرس سایت نیست. برای انتقال صحیح باید ابتدا SSL را فعال و آزمایش کنید، آدرس‌های وردپرس را در صورت نیاز تغییر دهید، ریدایرکت 301 را به‌شکل صحیح اجرا کنید و سپس منابع، لینک‌های داخلی، canonical و Sitemap را بررسی کنید.

مهم‌ترین نکته این است که هر URL قدیمی به نسخه HTTPS متناظر خود منتقل شود و درخواست‌ها بدون حلقه یا زنجیره غیرضروری به مقصد نهایی برسند. اگر سایت پشت CDN یا Reverse Proxy قرار دارد، تنظیمات آن لایه نیز باید با وب‌سرور و وردپرس هماهنگ باشد.

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

سوالات متداول درباره ریدایرکت HTTP به HTTPS در وردپرس

آیا نصب SSL به‌تنهایی HTTP را به HTTPS منتقل می‌کند؟

خیر. نصب SSL امکان برقراری اتصال HTTPS را فراهم می‌کند، اما برای انتقال درخواست‌های HTTP باید ریدایرکت مناسب تنظیم شود.

بهترین نوع ریدایرکت از HTTP به HTTPS چیست؟

برای انتقال دائمی، معمولاً ریدایرکت 301 انتخاب مناسبی است. این انتقال باید URL قدیمی را به نسخه HTTPS متناظر آن هدایت کند.

آیا تغییر HTTP به HTTPS برای سئو ضرر دارد؟

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

اگر بعد از فعال کردن HTTPS سایت Redirect Loop شد چه کنیم؟

آدرس‌های وردپرس، قوانین .htaccess، افزونه‌های SSL و Redirect و تنظیمات CDN یا Reverse Proxy را بررسی کنید. در بسیاری از موارد، علت مشکل اجرای چند قانون متناقض یا تشخیص نادرست پروتکل است.

Mixed Content چیست؟

Mixed Content زمانی رخ می‌دهد که صفحه با HTTPS بارگذاری شود، اما برخی منابع آن مانند تصاویر، CSS، JavaScript یا فونت‌ها همچنان با HTTP درخواست شوند. این منابع باید شناسایی و در صورت امکان به HTTPS منتقل شوند.

آیا باید لینک‌های داخلی را بعد از HTTPS تغییر دهیم؟

بله. بهتر است لینک‌های داخلی مستقیماً به نسخه HTTPS اشاره کنند تا از ریدایرکت‌های غیرضروری جلوگیری شود.

آیا باید Sitemap را بعد از انتقال به HTTPS تغییر دهیم؟

بله. Sitemap باید URLهای نهایی HTTPS صفحات قابل ایندکس را معرفی کند. پس از اصلاح آن، وضعیت Sitemap را در Google Search Console بررسی کنید.

آیا باید Canonical را هم به HTTPS تغییر دهیم؟

بله. اگر نسخه ترجیحی سایت HTTPS است، canonical صفحات نیز باید به URL نهایی HTTPS اشاره کند تا سیگنال متناقضی درباره نسخه اصلی صفحه ایجاد نشود.

آیا برای HTTPS حتماً باید افزونه وردپرس نصب کنیم؟

خیر. اگر SSL و ریدایرکت در سطح سرور به‌درستی تنظیم شده باشند، برای انتقال HTTP به HTTPS الزاماً به افزونه نیاز ندارید.

آیا فایل .htaccess برای همه سایت‌های وردپرسی مناسب است؟

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

آیا بعد از انتقال به HTTPS باید وضعیت سایت را در Search Console بررسی کنیم؟

بله. وضعیت ایندکس صفحات HTTPS، Sitemap، خطاهای Crawl و URLهای مهم را بررسی کنید تا مطمئن شوید گوگل به نسخه نهایی صفحات دسترسی دارد.