خطای SSL در وردپرس

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

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

خطای SSL در وردپرس دقیقاً چیست؟

SSL (Secure Sockets Layer) و جانشین مدرنش TLS (Transport Layer Security)، پروتکل‌هایی هستند که ارتباط بین مرورگر کاربر و سرور شما را رمزنگاری می‌کنند. وقتی سایت شما روی HTTPS کار می‌کند، همهٔ داده‌های ردوبدل‌شده — از رمز عبور کاربر تا محتوای صفحات — در مسیر شبکه، رمزنگاری‌شده هستند و کسی نمی‌تواند محتوای آن‌ها را بخواند یا تغییر دهد.

خطای SSL در وردپرس، اصطلاحی کلی برای مجموعه‌ای از وضعیت‌هاست که در آن‌ها، این ارتباط امن برقرار نمی‌شود یا ناقص برقرار می‌شود. این وضعیت‌ها طیف متنوعی دارند: از پیام هشدار در مرورگر («اتصال شما امن نیست») تا خطای محتوای ترکیبی در کنسول مرورگر، تا شکست در ریدایرکت HTTPS، تا مشکل با گواهی منقضی. هرکدام از این‌ها، ریشه و مسیر رفع جداگانه‌ای دارند.

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

در لایهٔ فنی، وردپرس برای HTTPS به چند چیز وابسته است: گواهی نصب‌شده روی سرور، پیکربندی وب‌سرور، تنظیمات داخلی وردپرس (مقادیر siteurl و home)، و یکپارچگی منابع بارگذاری‌شده در صفحات. هر نقص در یکی از این‌ها، می‌تواند منجر به یک خطای متفاوت شود. به همین دلیل، در تجربهٔ خودم، تشخیص دقیق این نوع خطاها نیازمند نگاهی چند‌لایه‌ای است، نه یک نگاه تک‌کاناله.

خطای SSL، پیام «سایت من امن نیست» نیست؛ بیشتر وقت‌ها پیام «یک بخش از زنجیرهٔ امنیت، ناهماهنگ است» می‌دهد. تشخیص درست، از پیدا کردن همان حلقهٔ ناهماهنگ آغاز می‌شود.

چرا این خطاها مهم‌تر از آن هستند که به‌نظر می‌رسد؟

در سال‌های اخیر، HTTPS از یک «مزیت» به یک «الزام» تبدیل شده است. سه دلیل اصلی این تغییر را در پروژه‌های خودم به‌روشنی دیده‌ام:

• نرخ پرش کاربران: مرورگرها هنگام دیدن گواهی نامعتبر، یک صفحهٔ هشدار قرمز نمایش می‌دهند که کاربر را به «بازگشت به سایت» دعوت می‌کند. تجربهٔ من نشان می‌دهد که در چنین وضعیتی، بیش از نیمی از کاربران پیش از دیدن محتوای سایت، آن را ترک می‌کنند.
• ضربهٔ سئویی: گوگل از سال ۲۰۱۴ HTTPS را به‌عنوان یک سیگنال رتبه‌بندی تأیید کرد. سایتی که HTTPS را ناقص پیاده کرده — یعنی محتوای ترکیبی دارد یا بخشی از صفحاتش روی HTTP است — به‌طور غیرمستقیم سیگنال ضعف به گوگل می‌فرستد. توضیح کامل این چرخه در سئو تکنیکال چیست آمده است.
• مشکلات عملکردی: بعضی از قابلیت‌های مدرن وب — از جمله Geolocation، Notification، Service Worker — فقط روی HTTPS کار می‌کنند. اگر HTTPS شما ناقص باشد، این قابلیت‌ها در مرورگر مسدود می‌شوند و کاربران تجربهٔ ناقصی دارند.

نکتهٔ مهمی که در پروژه‌های خودم زیاد به آن برخورده‌ام: اهمیت خطای SSL فقط در «لحظهٔ وقوع» نیست؛ در ترند بلندمدت است. سایتی که چند ماه با HTTPS ناقص کار می‌کند، در آمار خود کاهش تدریجی ترافیک را می‌بیند، بدون اینکه علت را به HTTPS نسبت دهد. به همین دلیل، در هر بازبینی فصلی سایت، من همیشه SSL را به‌عنوان یکی از ستون‌های پایه چک می‌کنم — دقیقاً همان‌طور که در بهترین افزونه‌های امنیتی وردپرس به لایهٔ HTTPS به‌عنوان یکی از لایه‌های دفاعی اشاره کرده‌ام.

آناتومی یک اتصال امن در وردپرس

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

1. گرهٔ اول — گواهی SSL: سرور شما، یک گواهی دیجیتال دارد که توسط یک مرجع معتبر (CA) امضا شده. این گواهی، هویت سرور شما را تأیید می‌کند.
2. گرهٔ دوم — دست‌دادن TLS (TLS Handshake): وقتی مرورگر به سرور وصل می‌شود، این دو، یک توافق رمزنگاری می‌کنند. اگر این توافق شکست بخورد، هیچ اتصال امنی برقرار نمی‌شود.
3. گرهٔ سوم — پیکربندی وب‌سرور: وب‌سرور شما (Apache یا Nginx) باید برای پذیرش و پاسخ به HTTPS پیکربندی شده باشد.
4. گرهٔ چهارم — تنظیمات وردپرس: مقادیر siteurl و home در دیتابیس، و قوانین ریدایرکت، تعیین می‌کنند که سایت شما به‌درستی روی HTTPS هدایت شود.
5. گرهٔ پنجم — یکپارچگی منابع: همهٔ منابع بارگذاری‌شده در صفحات — تصاویر، CSS، JS، فونت‌ها — باید از همان پروتکل HTTPS بارگذاری شوند. اگر یکی از آن‌ها HTTP باشد، مرورگر هشدار «محتوای ترکیبی» می‌دهد.

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

انواع خطاهای SSL که در پروژه‌ها دیده‌ام

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

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

گروه اول: خطاهای مربوط به گواهی

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

علت‌های رایج در پروژه‌های من:

• گواهی منقضی شده: گواهی‌های SSL، تاریخ انقضا دارند (معمولاً یک‌ساله یا سه‌ماهه). اگر تمدید نشوند، مرورگر آن‌ها را نامعتبر می‌داند.
• گواهی self-signed: بعضی هاست‌ها یا ابزارها، گواهی‌هایی نصب می‌کنند که خودشان امضا کرده‌اند. این گواهی‌ها از نگاه مرورگر معتبر نیستند.
• عدم تطابق دامنه: گواهی برای دامنهٔ example.com صادر شده اما سایت روی www.example.com یا یک زیردامنه باز می‌شود.
• زنجیرهٔ ناقص گواهی: گواهی شما معتبر است اما زنجیرهٔ کامل به مرجع ریشه (Root CA) به‌درستی روی سرور نصب نشده.
• گواهی با نام دامنهٔ قدیمی: بعد از تغییر دامنه، گواهی برای دامنهٔ قدیمی باقی مانده.

تشخیص: از ابزارهای آنلاین مثل SSL Labs یا Whatsmydns، وضعیت گواهی سایت خود را ببینید. این ابزارها معمولاً جزئیات دقیق‌تری از مرورگر به شما می‌دهند: تاریخ انقضا، زنجیرهٔ گواهی، پروتکل TLS و رمزنگاری. یک راه سریع‌تر: از خط فرمان با curl -vI https://yourdomain.com اطلاعات گواهی را ببینید.

رفع: بسته به علت، رفع متفاوت است. اگر گواهی منقضی شده، از پنل هاست آن را تمدید کنید. اگر self-signed است، از یک مرجع معتبر (مثل Let’s Encrypt به‌صورت رایگان یا یک گواهی پولی) استفاده کنید. اگر عدم تطابق دامنه است، گواهی جدیدی صادر کنید که همهٔ نسخه‌های دامنه (با www و بدون www) را پوشش دهد. اگر زنجیرهٔ گواهی ناقص است، از پشتیبانی هاست بخواهید که زنجیره را به‌طور کامل نصب کند.

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

گروه دوم: خطای محتوای ترکیبی (Mixed Content)

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

ماهیت Mixed Content این است: صفحهٔ شما از HTTPS بارگذاری می‌شود، اما بعضی از منابع درون آن — تصویر، CSS، JS، یا فونت — از HTTP بارگذاری می‌شوند. مرورگر، این وضعیت را «نیمه‌امن» می‌داند و هشدار می‌دهد.

علت‌های رایج در پروژه‌های من:

• لینک‌های قدیمی HTTP در محتوا: وقتی سایت به HTTPS منتقل می‌شود، لینک‌های تصاویر یا فایل‌های درون نوشته‌ها همچنان HTTP هستند.
• کدهای سفارشی قالب: فایل‌های CSS یا JS که به‌صورت مستقیم با آدرس HTTP لینک شده‌اند.
• افزونه‌هایی که با HTTP کار می‌کنند: بعضی افزونه‌ها، اسکریپت‌های خود را از دامنهٔ خودشان با پروتکل HTTP بارگذاری می‌کنند.
• CDN با تنظیمات ناهماهنگ: اگر بخشی از منابع از CDN و بخشی دیگر از سرور اصلی بارگذاری شود، ممکن است پروتکل‌ها ناهماهنگ شوند.
• فونت‌های Google یا سایر سرویس‌های بیرونی: اگر فونت یا آیکون‌ها از یک سرویس بیرونی با HTTP بارگذاری می‌شوند، Mixed Content رخ می‌دهد.

تشخیص: در مرورگر، کلید F12 را بزنید تا کنسول باز شود. در سربرگ Console، به دنبال پیام‌های «Mixed Content» بگردید. مرورگر به‌طور دقیق نشان می‌دهد کدام منبع با HTTP بارگذاری شده است. در سربرگ Network هم می‌توانید فیلتر کنید تا درخواست‌های HTTP را در میان درخواست‌های HTTPS ببینید.

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

رفع: سه مسیر دارید:

1. استفاده از افزونه‌های اصلاح خودکار: افزونه‌هایی مثل «Really Simple SSL» یا «SSL Insecure Content Fixer» می‌توانند به‌صورت خودکار لینک‌های HTTP را در محتوا، ویجت‌ها و کدهای قالب جایگزین کنند. این روش، سریع‌ترین راه برای رفع محتوای ترکیبی است اما در سایت‌های حجیم، ممکن است نیاز به تنظیمات دقیق‌تری داشته باشد.
2. جستجو و جایگزینی در دیتابیس: از ابزار Search-Replace-DB یا WP-CLI برای جایگزینی http://yourdomain.com با https://yourdomain.com در کل دیتابیس استفاده کنید. این کار، حساس است و پیش از اجرا باید بکاپ کامل بگیرید — روشش در چگونه از سایت وردپرسی بکاپ بگیریم.
3. اصلاح دستی منابع بیرونی: اگر Mixed Content از منابع بیرونی (مثل Google Fonts) می‌آید، در کد قالب یا افزونهٔ مربوطه، آدرس HTTP را به HTTPS تغییر دهید.

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

گروه سوم: حلقهٔ ریدایرکت HTTPS و HTTP

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

علت‌های رایج در پروژه‌های من:

• تناقض دیتابیس و سرور: مقادیر siteurl و home در دیتابیس، هنوز روی HTTP هستند اما سرور به‌طور اجبار به HTTPS ریدایرکت می‌کند.
• بلوک‌های تکراری در .htaccess: دو بلوک ریدایرکت که یکی به HTTPS و دیگری به HTTP اصرار دارد.
• افزونهٔ ریدایرکت با قوانین ناسازگار: یک افزونهٔ ریدایرکت، خودش قانون HTTPS اضافه می‌کند که با قوانین سرور تعارض دارد.
• ناهماهنگی CDN: اگر CDN بخواهد از HTTPS استفاده کند اما سرور مبدأ به HTTP ریدایرکت کند، حلقه شکل می‌گیرد.

تشخیص: از phpMyAdmin، جدول wp_options را باز کنید و مقادیر siteurl و home را با دامنهٔ واقعی سایت مقایسه کنید. سپس فایل .htaccess را باز کنید و بلوک‌های ریدایرکت را یکی‌یکی ببینید. اگر بیش از یک بلوک ریدایرکت HTTPS دارید، احتمال تعارض بالاست. موضوع مشابهی را در رفع خطای حلقۀ ریدایرکت وردپرس به تفصیل باز کرده‌ام؛ اگر بعد از خواندن این بخش، همچنان در حلقه گیر کرده‌اید، آن مقاله نقطهٔ شروع دقیقی است.

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

UPDATE wp_options SET option_value = 'https://yourdomain.com' WHERE option_name = 'siteurl';
UPDATE wp_options SET option_value = 'https://yourdomain.com' WHERE option_name = 'home';

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

گروه چهارم: خطاهای مربوط به HSTS

HSTS (HTTP Strict Transport Security) یک سیاست امنیتی است که به مرورگر می‌گوید: «برای این دامنه، همیشه از HTTPS استفاده کن و حتی اگر کاربر آدرس HTTP را وارد کرد، مستقیم به HTTPS برو.» این سیاست، امنیت را بالا می‌برد، اما اگر به‌اشتباه فعال شود، می‌تواند دسترسی به سایت را کاملاً قطع کند.

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

تشخیص: اگر بعد از هر تغییری در HTTPS، سایت از دسترس خارج شد و هیچ راهی برای بازگشت نداشتید، احتمال زیادی وجود دارد که HSTS مقصر باشد. مرورگر Chrome، یک صفحهٔ داخلی به نام chrome://net-internals/#hsts دارد که در آن می‌توانید دامنهٔ خود را جستجو کنید و ببینید آیا HSTS فعال است یا نه.

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

1. از سمت سرور، HTTPS را دوباره فعال کنید: اگر به‌سرعت می‌توانید HTTPS را بازگردانید، کاربران به‌طور خودکار به سایت برمی‌گردند.
2. حذف HSTS از مرورگر کاربران: کاربران می‌توانند از طریق chrome://net-internals/#hsts دامنهٔ شما را در فهرست «Delete domain security policies» حذف کنند. اما این راه‌حل، نیاز به دخالت کاربر دارد و مقیاس‌پذیر نیست.
3. استفاده از دامنهٔ جایگزین: اگر HSTS روی دامنهٔ اصلی گیر کرده، می‌توانید موقتاً از یک دامنهٔ جایگزین استفاده کنید تا مشکل حل شود.

درسی که از این وضعیت در پروژه‌های خودم گرفته‌ام: HSTS را فقط با مدت کوتاه (مثلاً یک هفته) و با احتیاط فعال کنید. بعد از مطمئن‌شدن از پایداری HTTPS، مدت را به‌تدریج افزایش دهید. هرگز با یک تیر، مدت طولانی را اعمال نکنید.

گروه پنجم: ناهماهنگی SSL در CDN

اگر سایت شما پشت یک CDN (Content Delivery Network) است، SSL می‌تواند در دو نقطه اعمال شود: بین کاربر و CDN، و بین CDN و سرور مبدأ. اگر این دو نقطه با هم هماهنگ نباشند، خطاهای عجیبی رخ می‌دهد.

علت‌های رایج در پروژه‌های من:

• حالت SSL نامناسب: در Cloudflare، حالت «Flexible SSL» یعنی CDN به کاربر HTTPS می‌دهد اما به سرور مبدأ HTTP وصل می‌شود. اگر سرور شما به HTTPS ریدایرکت کند، حلقه شکل می‌گیرد.
• گواهی نامعتبر روی سرور مبدأ: اگر سرور مبدأ گواهی معتبری نداشته باشد و CDN در حالت Full (Strict) باشد، اتصال شکست می‌خورد.
• قوانین ریدایرکت در CDN: بعضی CDNها امکان تعریف ریدایرکت دارند که با سرور مبدأ تعارض پیدا می‌کند.
• کش CDN نامنطبق: اگر CDN نسخهٔ قدیمی یک صفحه را با ریدایرکت اشتباه سرو کند، حلقه رخ می‌دهد.

تشخیص: اگر خطای SSL فقط در شبکهٔ عمومی دیده می‌شود اما از داخل شبکهٔ اداری یا با تست مستقیم به سرور مشکلی نیست، مقصر CDN است. از پنل CDN، تنظیمات SSL را بررسی کنید. حالت توصیه‌شده معمولاً Full (Strict) است — یعنی هم بین کاربر و CDN، هم بین CDN و سرور مبدأ، HTTPS استفاده می‌شود و گواهی سرور مبدأ هم معتبر است.

رفع: تنظیمات CDN را با سرور مبدأ هم‌راستا کنید. اگر مطمئن نیستید، به‌طور موقت CDN را در حالت «DNS Only» بگذارید تا ترافیک مستقیم به سرور برود و مشکل را ببینید. اگر رفت، مسئله در تنظیمات SSL CDN است.

گروه ششم: اختلال در ورود به پیشخوان

یکی از آزاردهنده‌ترین حالت‌ها، وقتی است که خطای SSL فقط در پیشخوان ظاهر می‌شود. سایت برای بازدیدکننده عادی کاملاً سالم است، اما شما نمی‌توانید وارد پیشخوان شوید — مدام به صفحهٔ ورود برگردانده می‌شوید یا با پیام «Your session has expired» روبه‌رو می‌شوید.

این وضعیت، معمولاً به یکی از این سه دلیل رخ می‌دهد:

• مقادیر siteurl و home ناهماهنگ: اگر یکی از این مقادیر HTTP و دیگری HTTPS باشد، وردپرس نمی‌تواند نشست را به‌درستی مدیریت کند.
• کوکی‌های گیرکرده: کوکی‌های قدیمی که با یک پروتکل تنظیم شده‌اند، در پروتکل جدید کار نمی‌کنند.
• افزونه‌های امنیتی سخت‌گیر: بعضی افزونه‌ها، اتصال را در شرایط خاص مسدود می‌کنند.

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

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

گروه هفتم: افت ایندکس در سرچ کنسول

یکی از خانواده‌های پنهان خطای SSL، حالتی است که هیچ خطای ظاهری نمی‌بینید اما گوگل به‌تدریج صفحات شما را از ایندکس خارج می‌کند. نشانه‌اش مشخص است: در Search Console، بخش Coverage یا Pages، به‌تدریج خطاهای جدید ظاهر می‌شود و ترافیک ارگانیک سایت کاهش می‌یابد.

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

تشخیص: در Search Console، بخش «Security Issues» یا «Manual Actions» را ببینید. اگر هشدار «Mixed Content» دیدید، مقصر پیدا شده. همچنین، در بخش Coverage، خطاهای مربوط به HTTPS را بررسی کنید.

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

روش گام‌به‌گام تشخیص

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

1. آیکون قفل مرورگر را ببینید. اگر قفل کامل است، HTTPS به‌درستی کار می‌کند. اگر شکسته یا خاکستری است، Mixed Content یا گواهی نامعتبر دارید.
2. کنسول مرورگر را باز کنید. پیام‌های Mixed Content و خطاهای مربوط به گواهی، در اینجا با جزئیات نمایش داده می‌شوند.
3. از ابزار SSL Labs استفاده کنید. این ابزار، وضعیت کامل گواهی و پیکربندی TLS را نشان می‌دهد.
4. مقادیر siteurl و home را در دیتابیس چک کنید. این ساده‌ترین لایه است و در بسیاری از موارد، مقصر همین‌جاست.
5. .htaccess را باز کنید. بلوک‌های ریدایرکت را یکی‌یکی ببینید و تعارض‌ها را شناسایی کنید.
6. تنظیمات CDN را چک کنید. اگر سایت پشت CDN است، حالت SSL و قوانین ریدایرکت را بررسی کنید.
7. Search Console را بازبینی کنید. در بخش Security Issues، خطاهای مرتبط با HTTPS را ببینید.

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

ابزارهای معتبر برای بررسی SSL

چهار ابزار که در پروژه‌های خودم زیاد استفاده می‌کنم و در تشخیص خطاهای SSL نقش کلیدی داشته‌اند:

یک — SSL Labs (ssllabs.com): ابزار مرجع برای بررسی جامع گواهی و پیکربندی TLS. امتیاز A تا F می‌دهد و جزئیات دقیقی از زنجیرهٔ گواهی، پروتکل‌ها و رمزنگاری‌های پشتیبانی‌شده ارائه می‌کند. اگر امتیاز شما کمتر از A است، احتمالاً پیکربندی سرور نیاز به بهبود دارد.

دو — Why No Padlock (whynopadlock.com): ابزاری ساده برای تشخیص محتوای ترکیبی. صفحه را باز می‌کند و فهرست دقیقی از تمام منابع HTTP در آن صفحه می‌دهد. این ابزار، در تشخیص Mixed Content بسیار مفید است.

سه — curl از خط فرمان: با دستور curl -vI https://yourdomain.com، می‌توانید زنجیرهٔ ریدایرکت‌ها و اطلاعات گواهی را ببینید. این ابزار برای تشخیص سریع، بسیار کاربردی است:

curl -vI https://yourdomain.com 2>&1 | grep -E "(SSL|HTTP|location|subject|issuer)"

چهار — DevTools مرورگر: در سربرگ Security، وضعیت امنیتی صفحه به‌طور کامل نمایش داده می‌شود. در سربرگ Console، هشدارهای Mixed Content با جزئیات دیده می‌شوند. در سربرگ Network، می‌توانید درخواست‌های HTTP را در میان HTTPS فیلتر کنید. این ابزار، برای پروژه‌های پیچیده، جامع‌ترین اطلاعات را می‌دهد.

رفع امن و راستی‌آزمایی

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

1. تست در چند مرورگر: سایت را در Chrome، Firefox و Safari باز کنید و آیکون قفل را در هر سه ببینید. اگر در همه سبز و کامل بود، مسئله رفع شده.
2. تست با ابزار SSL Labs: امتیاز سایت را در SSL Labs بررسی کنید. اگر امتیاز A یا A+ بود، پیکربندی شما سالم است.
3. بازبینی در Search Console: در بخش Security Issues، بررسی کنید که هشدارها رفع شده‌اند یا نه. رفع هشدارها، ممکن است چند روز طول بکشد.

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

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

اشتباهات رایج در مواجهه با خطای SSL

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

پیشگیری بلندمدت

پنج عادتی که در پروژه‌های خودم، نرخ خطاهای SSL را به کمترین حد رسانده است:

• گواهی SSL را از یک مرجع معتبر تهیه کنید: Let’s Encrypt رایگان و معتبر است؛ برای سایت‌های تجاری، گواهی پولی با پشتیبانی بیشتر، ارزشش را دارد.
• تاریخ انقضا گواهی را یادآوری کنید: یک یادآوری ماهانه در تقویم بگذارید. گواهی‌های منقضی، شایع‌ترین دلیل خطای SSL هستند.
• Mixed Content را زودتر از هر تغییر دیگر رفع کنید: بلافاصله بعد از انتقال به HTTPS، همهٔ منابع را بررسی کنید. تعویق این کار، به مشکل بلندمدت تبدیل می‌شود.
• از HSTS با احتیاط استفاده کنید: اگر تیم فنی محدودی دارید، شاید بهتر باشد HSTS را به‌کلی فعال نکنید.
• پایش ماهانه سایت را جدی بگیرید: با ابزارهایی مثل SSL Labs و Search Console، وضعیت HTTPS را هر ماه بررسی کنید.

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

نگاه مهندسی: HTTPS به‌مثابه قرارداد سیستم

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

یک — HTTPS، قرارداد بین سه طرف است، نه دو طرف. در نگاه سطحی، HTTPS یک رابطهٔ بین کاربر و سرور است. اما در معماری مدرن، سه طرف درگیرند: کاربر، CDN، و سرور مبدأ. اگر یکی از این سه نفر، پروتکل متفاوتی انتخاب کند، حلقه یا خطا رخ می‌دهد. به همین دلیل، در پروژه‌های خودم، همیشه تنظیمات SSL را در سطح این سه طرف هم‌راستا می‌کنم — در یک فایل مستندات، که مرجع نهایی است. این «منبع واحد حقیقت»، در برابر اکثر خطاهای آینده، مصونیت ایجاد می‌کند.

دو — Mixed Content، نشانهٔ نبود نظم در لایهٔ منابع است. اگر در سایت شما، لینک‌های HTTP و HTTPS به‌طور تصادفی قاطی شده‌اند، این نشانهٔ نبود یک سیاست روشن برای مدیریت منابع است. در معماری بالغ، هر منبع باید از یک مسیر مشخص بارگذاری شود — معمولاً از CDN یا سرور اصلی، همیشه با HTTPS. اگر تیمی برای مدیریت منابع ندارد، یک اسنیپت کوچک می‌تواند این نظم را برقرار کند: در زمان ذخیرهٔ محتوا، اگر لینکی با HTTP وارد شد، خودکار به HTTPS تغییر کند. این الگو، در پروژه‌هایی که با تیم‌های محتوایی غیرفنی کار می‌کنند، بسیار مؤثر است.

سه — HSTS، نمونه‌ای از تصمیم‌های برگشت‌ناپذیر است. در تئوری سیستم‌ها، تصمیم‌ها به دو دسته تقسیم می‌شوند: برگشت‌پذیر و برگشت‌ناپذیر. HSTS یک تصمیم برگشت‌ناپذیر است، چون در مرورگر کاربران ذخیره می‌شود و شما نمی‌توانید آن را به‌راحتی حذف کنید. همین ویژگی، HSTS را از یک «تنظیم ساده» به یک «تصمیم معماری» تبدیل می‌کند که باید با احتیاط و با پیش‌بینی پیامدها گرفته شود. تجربه‌ام این است که در پروژه‌های حساس، بهتر است HSTS با مدت کوتاه شروع شود و به‌تدریج افزایش یابد؛ و در تیم‌های کوچک، شاید بهتر باشد کلاً استفاده نشود.

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

سخن پایانی

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

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

اگر این خطا را روی سایت خودتان دیده‌اید و یکی از خانواده‌های این مقاله مقصر بوده، خوشحال می‌شوم در دیدگاه‌ها بخوانم. به‌ویژه اگر سناریوی نادری کشف کرده‌اید — مثلاً یک افزونهٔ خاص با یک رفتار غیرمعمول در HTTPS، یا یک سیاست سروری که کمتر دیده می‌شود — همان جزئیات برای خوانندهٔ بعدی که در همان موقعیت گرفتار است، از هر راهنمای عمومی ارزشمندتر است. اگر هم پس از خواندن این مقاله به این نتیجه رسیدید که هاست فعلی سقف شماست و مدیریت SSL روی آن پرچالش است، دو مقالهٔ راهنمای انتخاب هاست و تأثیر هاست بر سرعت سایت مسیر بعدی شما هستند. 🔒