بررسی و رفع خطای security:mixed content در اسکریمینگ فراگ
سلام به وبسایت حمید امیدی خوش آمدید.
فرض کنید یک صفحه در وبسایتتان دارید که با پروتکل امن HTTPS لود می شود، اما داخل آن یک تصویر، یک کد جاوا و یا کد CSS وجود دارد که با پروتکل HTTP (نا امن) لود می شود.
برای مثال صفحه ای مثل https://example.com که تصویری با آدرس http://example.com/image.png را لود می کند، دچار این مشکل است.
این وضعیت باعث می شود :
- امنیت HTTPS تضعیف شود.
- صفحه در برابر آسیب پذیری نامقاوم شود.(امکان دستکاری منابع توسط مهاجم)
- احتمال تأثیر منفی روی SEO و رتبه بندی (به خصوص اگر منابع مهم مشکل داشته باشند)
مرورگرهایی مثل کروم ممکن است این منابع HTTP را به طور خودکار مسدود کنند یا سعی کنند آن ها را به HTTPS ارتقا دهند که در هر دو حالت می تواند باعث خرابی ظاهر یا عملکرد صفحه شود.
چرا اسکریمینگ فراگ این خطا را گزارش می دهد
اسکریمینگ فراگ در حین خزش سایت، تمام لینک ها و منابع هر صفحه را بررسی می کند و پروتکل هر کدام (HTTP یا HTTPS) را ثبت می کند.
وقتی صفحه ای با پروتکل HTTPS بارگذاری شود ولی حاوی منبعی با پروتکل HTTP باشد، ابزار آن را به عنوان مشکل امنیتی زیر دسته Mixed Content علامت گذاری می کند.
نحوه پیدا کردن خطا در اسکرینینگ فراگ
برای مشاهده این مشکل:
- به تب Security بروید.
- فیلتر Mixed Content را انتخاب کنید تا فهرست صفحاتی که این مشکل را دارند نمایش داده شود.
- برای هر URL، در تب Outlinks می توانید منابع HTTP دقیقی که در آن صفحه لود می شوند را ببینید.
- برای گرفتن گزارش کامل از همه صفحات درگیر، از مسیر 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
اینجا یو آر ال هایی را داریم که مشکل محتوای مختلط دارند.
کاری که من میکنم این است که آن صفحه خاص را در مرورگر خودم باز میکنم و سپس روی صفحه کلیک راست میگیرم.

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 صفحه را باز کن.
- جستجو کن:
- ببین 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
۴.کرال قدیمی اسکریمینگ فراگ
اسکریمینگ فراگ بعد از برطرف کردن این خطا خود به خود آن را از لیست اخطار ها حذف نمی کند.
برای اینکه ببینید این خطا برطرف شده، باید دوباره کرال را انجام دهید.



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