خطای mixed content اسکریمینگ فراگ

بررسی و رفع خطای security:mixed content در اسکریمینگ فراگ

سلام به وبسایت حمید امیدی خوش آمدید.

فرض کنید یک صفحه در وبسایتتان دارید که با پروتکل امن HTTPS لود می شود، اما داخل آن یک تصویر، یک کد جاوا و یا کد CSS وجود دارد که با پروتکل HTTP (نا امن) لود می شود.

برای مثال صفحه ای مثل https://example.com که تصویری با آدرس http://example.com/image.png را لود می کند، دچار این مشکل است.

این وضعیت باعث می شود :

  • امنیت HTTPS تضعیف شود.
  • صفحه در برابر آسیب پذیری نامقاوم شود.(امکان دستکاری منابع توسط مهاجم)
  • احتمال تأثیر منفی روی SEO و رتبه‌ بندی (به‌ خصوص اگر منابع مهم مشکل داشته باشند)

مرورگرهایی مثل کروم ممکن است این منابع HTTP را به طور خودکار مسدود کنند یا سعی کنند آن ها را به HTTPS ارتقا دهند که در هر دو حالت می تواند باعث خرابی ظاهر یا عملکرد صفحه شود.

چرا اسکریمینگ فراگ این خطا را گزارش می دهد

اسکریمینگ فراگ در حین خزش سایت، تمام لینک ها و منابع هر صفحه را بررسی می کند و پروتکل هر کدام (HTTP یا HTTPS) را ثبت می کند.

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

نحوه پیدا کردن خطا در اسکرینینگ فراگ

برای مشاهده این مشکل:

  1. به تب Security بروید.
  2. فیلتر Mixed Content را انتخاب کنید تا فهرست صفحاتی که این مشکل را دارند نمایش داده شود.
  3. برای هر URL، در تب Outlinks می توانید منابع HTTP دقیقی که در آن صفحه لود می شوند را ببینید.
  4. برای گرفتن گزارش کامل از همه صفحات درگیر، از مسیر Bulk Export > Security > Mixed Content استفاده کنید تا خروجی کاملی از صفحات و منابع ناامن آن ها دریافت کنید.

همچنین می توانید بعد از اتمام خزش (crawl) ، به تب issues بروید و در آن قسمت security: mixed content را ببینید.

محتوای مختلط در اسکریمینگ فراگ

محتوای مختلط در اسکریمینگ فراگ

علل رایج بروز Mixed Content

  • لینک دهی مستقیم به تصاویر، اسکریپت ها یا فایل های CSS با پروتکل http:// در کد HTML یا در محتوای وارد شده توسط ویرایشگر (مثل ووردپرس)
  • استفاده از URLهای قدیمی HTTP که از قبل از مهاجرت سایت به HTTPS باقی مانده اند (شایع ترین)
  • بارگذاری منابع از CDN یا سرویس های شخص ثالث که هنوز HTTPS را پشتیبانی نمی کنند یا به اشتباه با HTTP فراخوانی شده اند.(کمتر دیده ام)
  • استفاده از پروتکل نسبی (protocol relative) در برخی موارد قدیمی که به اشتباه به HTTP resolve می شود

نکته : پروتکل نسبی یعنی چه؟ پروتکل نسبی یعنی آدرس یک منبع بدون مشخص کردن http یا https نوشته شود.
مثال :

<script src=“//example.com/script.js”></script>

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

روش های رفع خطا

۱. جایگزینی مستقیم آدرس ها
تمام URL های HTTP شناسایی شده در گزارش را با نسخه HTTPS همان منبع جایگزین کنید. این کار معمولا از طریق ویرایش دستی HTML یا با استفاده از ابزارهای Search and Replace در CMS انجام می شود.

۲. بررسی سرویس های شخص ثالث و CDN
اگر منبع ناامن از یک CDN یا سرویس خارجی می آید، مطمئن شوید که آن سرویس از HTTPS پشتیبانی می کند و آدرس فراخوانی را به HTTPS تغییر دهید.

۳. تنظیم ریدایرکت سمت سرور
با تنظیم ریدایرکت ۳۰۱ از HTTP به HTTPS در سطح سرور (فایل htaccess. در آپاچی یا فایل تنظیمات Nginx) می توانید اطمینان حاصل کنید که حتی اگر لینکی به اشتباه با HTTP فراخوانی شود، به نسخه امن هدایت می شود.

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

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

بیایید عملی ببینیم :

لطفا به تصویر نگاه کنید :

یو آر ال های حاوی mixed content

یو آر ال های حاوی mixed content

اینجا یو آر ال هایی را داریم که مشکل محتوای مختلط دارند.

کاری که من میکنم این است که آن صفحه خاص را در مرورگر خودم باز میکنم و سپس روی صفحه کلیک راست میگیرم.

view page source

view page source

بعد که وارد سورس صفحه شدم، CTRL+F را میگیرم تا باکس جستجو برایم باز شود و در آن سرچ می کنم HTTP:// .

در این حالت تمامی پروتکل های نا امن در سورس صفحه به من نمایش داده می شود و می توانم ببینم این آدرس ها مربوط به چه فایل ها یا کد هایی هستند.

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

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

این یک فایل تصویر با فرمت WEBP است.

در این حالت (اگر سایت وردپرسی است) به بخش رسانه ها می روم و تصویر را پیدا می کنم و آدرس آن را به HTTPS تغییر می دهم.

نکته :

در وردپرس ممکن است URLهای HTTP در دیتابیس ذخیره شده باشند.

در این حالت تغییر دستی فایل کافی نیست و باید با ابزارهای Search & Replace کل دامنه از HTTP به HTTPS جایگزین شود.

وجود Canonical و ارتباط آن با Mixed Content

تعریف ساده کنونیکال این است:
تگ Canonical به موتورهای جستجو می‌گوید نسخه اصلی یک صفحه کدام URL است.

هر صفحه در قائده کلی باید به خودش یک کنونیکال داشته باشد (مگر در شرایط خاص یا زمانی که دو صفحه از نظر محتوایی کاملا شبیه به هم هستند).

موضوع اینجاست که گاهی ما کنونیکال یک صفحه را با نسخه HTTP داده ایم، به مثال دقت کنید :

<link rel=“canonical” href=“http://example.com/page”>

اسکریمینگ فراگ در این حالت هم خطای mixed content خواهد داد.

در این حالت یک سیگنال اشتباه به گوگل داده می‌شود. این مورد معمولاً Mixed Content مستقیم ایجاد نمی‌کند (چون canonical یک منبعی نیست که مرورگر آن را لود کند)، اما یک مشکل مهاجرت HTTPS و سئو محسوب می‌شود و بهتر است اصلاح شود.

برای بررسی:

  • View Source صفحه را باز کن.
  • جستجو کن:
Canonical
  • ببین URL داخل آن با HTTPS است یا نه.

چرا بعد از برطرف کردن خطا، باز هم آن را میبینم؟

گاهی URL مشکل‌ دار را اصلاح می‌کنی ولی Screaming Frog یا مرورگر هنوز Mixed Content نشان می‌دهد. دلایل رایج:

۱. کش وردپرس

افزونه‌های کش مثل:

  • LiteSpeed Cache
  • WP Rocket
  • WP Super Cache

ممکن است نسخه قدیمی HTML را نگه داشته باشند.

راه‌حل:

  • پاک کردن Cache افزونه
  • دوباره Crawl گرفتن

۲. کش CDN

اگر از CDN مثل Cloudflare استفاده می‌کنی، ممکن است نسخه قدیمی فایل‌ها یا HTML ذخیره شده باشد.

راه‌حل:

  • Purge Cache در CDN
  • دوباره تست

۳. کش مرورگر

گاهی مرورگر نسخه قبلی صفحه را نشان می‌دهد.

راه‌حل:

  • Ctrl + F5
  • یا باز کردن صفحه در حالت Incognito

۴.کرال قدیمی اسکریمینگ فراگ

اسکریمینگ فراگ بعد از برطرف کردن این خطا خود به خود آن را از لیست اخطار ها حذف نمی کند.

برای اینکه ببینید این خطا برطرف شده، باید دوباره کرال را انجام دهید.

سوالات متداول کاربران درباره محتوای مختلط

۱. آیا خطای Mixed Content باعث افت رتبه سایت در گوگل می‌شود؟

به‌صورت مستقیم معمولاً یک عامل رتبه‌بندی مستقل نیست، اما اگر باعث خراب شدن ظاهر صفحه، مسدود شدن فایل‌های مهم (مثل CSS و JavaScript)، کاهش تجربه کاربری یا مشکل در ایندکس شود، می‌تواند به شکل غیرمستقیم روی سئو اثر بگذارد.


۲. آیا تغییر آدرس سایت از HTTP به HTTPS به‌تنهایی Mixed Content را حل می‌کند؟

خیر. تغییر آدرس سایت و فعال کردن SSL فقط باعث می‌شود صفحات اصلی با HTTPS باز شوند.

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


۳. آیا همه خطاهای Mixed Content باید حتماً برطرف شوند؟

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

منابع مهم‌تر مثل JavaScript، CSS و فونت‌ها اولویت بالاتری برای اصلاح دارند.


۴. چگونه بفهمیم مشکل Mixed Content از قالب سایت است یا از محتوای صفحات؟

می‌توان با بررسی محل قرارگیری URL مشکل‌دار تشخیص داد:

  • اگر داخل HTML نوشته‌ها یا تصاویر صفحات باشد → احتمالاً از محتوا یا دیتابیس است.
  • اگر داخل فایل‌های CSS یا JS قالب باشد → مشکل از قالب یا افزونه‌هاست.
  • اگر از دامنه خارجی باشد → مربوط به سرویس شخص ثالث است.

۵. آیا استفاده از افزونه‌های SSL Fixer برای رفع Mixed Content کافی است؟

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

بهتر است URLهای HTTP در منبع اصلی (دیتابیس، قالب، محتوا و تنظیمات افزونه‌ها) اصلاح شوند تا مشکل ریشه‌ای برطرف شود.

0 پاسخ

دیدگاه خود را ثبت کنید

تمایل دارید در گفتگوها شرکت کنید؟
در گفتگو ها شرکت کنید.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *