https چیست
HTTPS مخفف HyperText Transfer Protocol Secure است. این عبارت به معنای پروتکل امن انتقال ابر متنها میباشد. HTTPS یک نسخه رمزگذاری شده از HTTP است. HTTP پروتکل اصلی انتقال دادهها در شبکه جهانی وب است. آشنایی با https و نحوه کار با https یکی از ملزومات سئو تکنیکال است.
- HTTPS چیست؟
- مفاهیم پایه HTTP و HTTPS
- نحوه عملکرد گواهینامههای TLS
- تاثیرات مثبت HTTPS در سئو
- نحوه استفاده از HTTPS
- بررسی خطاهای احتمالی انتقال از HTTP به HTTPS
دقیقا HTTPS چیست؟
- HTTPS رابطه بین مرورگر و سرور را حفظ میکند تا توسط مهاجمان قطع و دستکاری نشود.
- HTTPS قابل اعتماد، بیعیب و معتبر بودن اکثر ترافیک وب WWW امروزه را فراهم میکند.
- هر وبسایتی که در نوار آدرس خود نماد قفل را دارد، از HTTPS استفاده میکند.
- https یکی از سیگنالهای تجربه کاربری از نظر گوگل است و فاکتور رتبه بندی است.
مفاهیم پایه HTTP و HTTPS
ابتدا اجازه دهید ارتباط بین کاربر (مرورگر) و سرور را هنگامی که یک مهاجم بین آنهاست، شرح دهم.
همانطور که میبینید، مهاجمان میتوانند اطلاعات حساسی مانند جزییات ورودی و پرداخت را در اختیار داشته باشند یا کد مخرب را به منابع درخواست شده بفرستند.
حملات احتمالی شبکه ممکن است در هر مکانی با یک ISP نامعتبر اتفاق بیفتد. بنابراین هر شبکه WiFi عمومی در برابر چنین حملاتی آسیبپذیر است.
بنابراین، همه بار مسئولیت ایمنسازی وب بر عهده مدیران وب است و باید نیز اینطور باشد. اینجاست که موضوع HTTPS مطرح میشود.
HTTPS درخواستها و پاسخهای HTTP را رمزگذاری میکند. بنابراین به عنوان مثال، یک مهاجم قطعکننده ارتباط به جای مشاهده اطلاعات کارت اعتباری (یا سایر اطلاعات حساس) فقط کاراکترهای کدنگاری شده را میبیند.
تفاوت نحوه عملکرد HTTPS این است که دادههای ارزشمند را به یک جعبه ترکیبی قفل شده فناناپذیر ارسال میکند. فقط طرفین فرستنده و گیرنده از این ترکیب اطلاع دارند. اگر هم مهاجمان به آن دست پیدا کنند، وارد آن نمیشوند.
در حال حاضر، هنگام ایجاد اتصال HTTPS بسیاری از اتفاقات رخ میدهد. اصولا، HTTPS برای ایمن سازی اتصالات به رمزگذاری TLS (لایه امنیت انتقال) نیاز دارد.
نحوه عملکرد گواهینامههای TLS
تنها راه فعال کردن HTTPS در وبسایت شما، دریافت گواهینامه TLS و نصب آن بر روی سرور است. همچنین ممکن است با گواهینامههای SSL یا SSL/TLS نیز روبرو شوید اما نگران نباشید. همه اینها یکسان هستند. در SSL هنوز از اصطلاحات گستردهای استفاده میشود. درحالی که همه ما از لحاظ فنی از TLS که جانشین آن شده است استفاده میکنیم.
گواهینامههای TLS توسط مسئولین گواهینامه (CA) صادر میشوند. CA در ارتباط با سرور کاربر نقش یک شخص ثالث مورد اعتماد را دارد. اساسا، هرکسی میتواند گواهینامه TLS را صادر کند. اما فقط مسئولین مورد اعتماد عموم، توسط مرورگران پشتیبانی میشوند.
با کلیک کردن بر نماد قفل در نوار آدرس مرورگر خود میتوانید گواهینامه TLS و CA صادرکننده هر وبسایتی را بررسی کنید.
برای کسب اطلاعات بیشتر در مورد گواهینامهها میتوانید بعد از کلیک روی قفل، روی عبارت connection is secure و سپس cerificate is valid کلیک کنید. نکته مهم در اینجا خط Issued to است. این عبارت همان چیزی است که گواهینامههای پولی و رایگان را از هم جدا میکند. در هنگامی که به انواع مختلفی از استانداردهای اعتبارسنجی گواهینامههای TLS میرسیم.
DV ,OV و EV به چه معنا هستند و کدام را انتخاب کنیم؟
گواهینامههای رایگان TLS که با میزبانی و برنامههای CDN شما ارائه میشوند، فقط اعتباربخشی به دامنه (DV) را انجام میدهند. این تاییدی است که صاحب گواهینامه نام دامنه مشخصی را کنترل میکند. چنین روش اعتبار بخشی ابتدایی مناسب وبلاگها و وبسایتهایی است که اطلاعات حساسی را در اختیار ندارند. اما برای آنهایی که اطلاعات مهمی را دارند مناسب نیست.
وبسایتهایی که از گواهینامه DV TLS استفاده میکنند، ایمن به نظر میرسند. اما هنگامی که بر روی نماد قفل کلیک میکنید، خط ″Issued to″ را مشاهده نمیکنید.
رایجترین گواهینامه DV TLS از یک CA غیرانتفاعی به نام Let’s Encrypt گرفته میشود. این همان چیزی است که اکثر شرکتهایی که گواهینامههای تجدیدپذیر TLS رایگان ارائه میدهند، از آن استفاده میکنند.
فقط گواهینامههای DV هستند که هیچ مشکلی ندارند. از این گذشته، تنها نوع از گواهینامه TLS است که میتواند بطور خودکار در مناسبترین اندازه صادر شود. با این حال، HTTPS تنها به اندازه گواهینامه اصولی قوی است که مورد اعتماد سرور مورد بحث شما باشد.
اگر وبسایت شما امکان پرداخت آنلاین را دارد، باید از گواهینامه TLS استفاده کنید که اعتباربخشی به سازمان (OV) یا اعتباربخشی گسترده (EV) را ارائه میدهند. فرایند تایید این دو باهم متفاوت است. EV دقیقتر است.
اگر میخواهید فقط یکی از این دو را بخرید، توصیه میکنم مستقیما سراغ گواهی EV TLS بروید. این نوع معتبرترین است و هزینه آن نیز بیشتر از OV نیست.
گواهینامههای Wild Card و SAN TLS
بعد از نکات مربوط به استانداردهای اعتباربخشی، حالا نوبت به دسته دیگری از گواهینامههای TLS میرسد.
از گواهینامههای SAN و Wild Card برای ایمن سازی چندین دامنه (فرعی) به طور همزمان استفاده میشود. اگر برای example.com گواهینامه استاندارد EV TLS را خریداری کردهاید، برای blog.example.com به گواهی جداگانهای نیاز دارید.
گواهینامههای Wild Card میتوانند زیردامنههای نامحدود (مانند blog.example.com, example.com, docs.example.com) را ایمن کنند. درحالی که گواهینامههای SAN علاوه بر آنها میتوانند دامنههای دیگری را نیز ایمن کنند (example.com, blog.example.com, different.org).
این نوع از گواهینامهها با گواهینامههای اعتباربخشی ترکیب شدهاند. بنابراین هنگام جستجوی گزینههایی که CAها ارائه میدهند، همه نوع ترکیبی را مشاهده خواهید کرد. همچنین آنها شما را از طریق مراحل اعتباربخشی نیز راهنمایی خواهند کرد.
تاثیرات مثبت HTTPS برای سئو
داشتن HTTPS فواید زیادی برای سئو دارد:
- سیگنال رتبهبندی خفیف
- حریم خصوصی و امنیت بهتر
- ارتباط با سیستمهای آنالیز دادهها
- امکان استفاده از پروتکلهای جدید که امنیت و سرعت سایت را افزایش میدهند.
سیگنال رتبهبندی خفیف
گوگل در سال ۲۰۱۴ و در پست وبلاگی خود اعلام کرد که HTTPS یک عامل رتبهبندی است.
در چند ماه گذشته، آزمایشهایی را با در نظر گرفتن اینکه آیا سایتها از اتصالات امن و رمزگذاری شده به عنوان سیگنال در الگوریتمهای رتبهبندی جستجوی ما استفاده میکنند، اجرا کردهایم. ما نتایج مثبتی دیدهایم، بنابراین شروع به استفاده از HTTPS به عنوان سیگنال رتبهبندی کردهایم.
امنیت و حریم خصوصی بهتر
قبلا درمورد این موضوع صحبت کردهایم. اما این موضوع چه ربطی به سئو دارد؟
هنگامی که در وبسایت ناامنی قرار میگیرید، چیزی شبیه به این را خواهید دید:
این جمله سبب بیاعتمادی ما نسبت به آن سایت میشود. درست است؟ ما معمولا در حدی حرفهای هستم که فریب نخوریم. اما اگر آن جمله را در هر وبسایتی مشاهده کنم، به سرعت تصور بدی از آن وبسایت در ذهنم شکل میگیرد.
حدس میزنم که انتقال به HTTPS زمان استفاده از وبسایت را افزایش می دهد و همچنین مانع از پوگو استیکینگ میشود. اینها فقط عوامل رتبهبندی نظریه پردازی شده (تایید نشده) هستند. ماندن افراد در وبسایت شما حتی بدون توجه به سئو، خواسته شما است.
ارتباط با سیستمهای آنالیز دادهها
اگر هنوز وبسایت شما در HTTP قرار دارد و از سرویسهای تجزیهوتحلیلی مانند Google Analytics استفاده میکنید، خبر بدی برای شما دارم. هیچ داده ارجاعی از HTTPS به صفحات HTTP منتقل نمیشود.
ابن روزها، اکثر صفحات وب در بستر HTTPS اجرا میشوند. اگر سایت شما HTTP باشد برای ارتباط با نرمافزارهای آنالیز داده به مشکل بر میخورید.
امکان استفاده از پروتکلهای جدید که امنیت و سرعت سایت را افزایش میدهند.
بطور فرض ، سرعت HTTPS به دلیل برخورداری از ویژگیهای امنیتی از HTTP کمتر است. با این حال، داشتن HTTPS پیشنیاز استفاده از جدیدترین تکنولوژی امنیتی و عملکرد وب است.
به عبارت دیگر، علاوه بر امنیت سایت، HTTPS این امکان را به سایت شما میدهد که سرعت صفحه خود را بهبود بخشید. در هنگامی که از پروتکلهایی مانند HTTP/2 و TLS 1.3 استفاده میکنید.
جدا از تجربه کاربری بهتر، گوگل سرعت صفحه را همانند HTTPS یک عامل رتبهبندی خفیف در نظر میگیرد:
در جولای ۲۰۱۸، گوگل سرعت صفحه را به یک فاکتور رتبه بندی برای نتایج جستجوی موبایل تبدیل کرد.
در اطلاعیه گوگل آمده است:
کاربران می خواهند پاسخ سوالات خود را به سرعت بیابند و داده ها نشان می دهد که مردم واقعاً به سرعت بارگیری صفحات خود اهمیت می دهند. تیم جستجو اعلام کرد که سرعت در سال ۲۰۱۰ یک سیگنال رتبه بندی برای جستجوهای دسکتاپ خواهد بود و از این ماه (ژوئیه ۲۰۱۸)، سرعت صفحه یک عامل رتبه بندی برای جستجوهای موبایلی نیز خواهد بود.
نحوه تنظیم و استفاده از HTTPS در وبسایت شما
این مورد به موقعیت شما بستگی دارد.
۱. هنگامی که درحال راهاندازی یک وبسایت جدید هستید.
خیلی خوششانس هستید که قبل از راهاندازی وبسایت، متوجه اهمیت HTTPS شدهاید. پس از همین ابتدا باید با HTTPS به گوگل معرفی شوید.
تنها کاری که باید انجام دهید داشتن یک ارائهدهنده میزبانی خوب است. تا شما را در این فرآیند راهنمایی و از آخرین نسخههای پروتکل HTTP و TLS پشتیبانی کند.
دقت داشته باشید؛ برای نصب HTTPS روی سایتتان، باید از میزبان هاست یا سرور خود کمک بگیرید.
۲. هنگامی که قبلا یک وبسایت فعال HTTPS داشتهاید
اگر سایتتان الان دارای HTTPS است تنها کاری ک باید انجام دهید این است که چک کنید سایتتان مشکل نداشته باشد. برای بررسی خطاهای رایج، توصیههای بخش بعدی را دنبال کنید.
۳. هنگامی که هنوز وبسایتی دارید که از طریق HTTP اجرا میشود
مدتی طول میکشد تا همه چیز آماده انجام شود. پیچیدگی انتقال وبسایت شما از http به https به موارد زیر بستگی دارد:
- اندازه و پیچیدگی وبسایت شما
- نوع CMS که استفاده میکنید
- میزبانی/تامینکنندگان CDN شما
- تواناییهای فنی شما
معتقدم صاحبان وبسایتهای کوچکی که از CMS معروف و میزبانی قوی استفاده میکنند، می توانند خود انتقال را انجام دهند. اما در این بین متغیرهای بسیاری وجود دارند.
توصیه میکنم فایلهای آموزش CMS / سرور/ میزبانی / CDN خود را بررسی کنید. سپس به دقت طبق آن عمل کنید. مراحل زیادی را باید انجام دهید. بنابراین چک لیستی از انتقال را ایجاد کرده یا دنبال کنید و وارد فعالیت جدیدی نیز نشوید.
اگر این موارد برای شما فنی به نظر میرسند، متخصص حرفهای را استخدام کنید. با این کار ساعتها در وقت شما صرفهجویی میشود، ار بروز یک فاجعه جلوگیری میشود و کارکرد صحیح آن نیز تضمین میشود.
بررسی خطاهای احتمالی انتقال به HTTPS
حتی اگر کل چک لیست انتقال به HTTPS را مو به مو انجام داده باشید، به احتمال زیاد با مشکلاتی مواجهه میشوید. در سال ۲۰۱۶، ۱۰۰۰۰ دامنه با رتبههای بالا تجزیهوتحلیل شدند تا اشتباهات مختلف HTTPS بررسی شود. موارد زیر بیشترین تکرار را داشتهاند:
- ۹/۹۰٪ از دامنهها در اجرای HTTPS خیلی خوب عمل نکردند.
- در ۳۹/۶۵٪ از دامنهها HTTPS به درستی عمل نمیکرد.
- ۰۱/۲۳٪ از دامنهها از تغییر مسیر موقت ۳۰۲ به جای تغییر مسیر دائمی ۳۰۱ استفاده میکردند.
- بسیاری از آنها تغییر کرده و اصلاح شدهاند.
با این حال توصیه میکنم ۵ اشتباه رایج انتقال به HTTPS را در زیر بررسی کنید. خیلی طول نمیکشد و اصلاح اکثر آنها نیز چندان سخت نیست.
اشتباه ۱: هنگامی که صفحات HTTP باقی ماندهاند
اول از همه باید مطمئن شوید که همه صفحات شما اکنون به HTTPS انتقال یافتهاند.
با خزش کامل وبسایت میتوانید صفحات HTTP باقی مانده را کشف کنید. فقط مطمئن شوید که خزنده تمام منابع URL مورد نیاز را در اختیار دارد تا صفحات را جا نگذارد.
شاید بهترین راه برای خزش کل صفحات استفاده از نرم افزار screaming frog باشد. این نرمافزار مخصوص بررسی سئو سایت است و امکانات بسیار زیادی دارد.
یکی از مهمترین و کاربردیترین امکانات این نرم افزار، خزش اتوماتیک تمام صفحات سایت است.
طبق تصاویر زیر عمل کنید.
اشتباه ۲: هنگامی که صفحات HTTPS محتوای HTTP را دارند.
این اشتباه هنگامی رخ میدهد که فایل HTML قبلا با استفاده از HTTP آدرسدهی شده باشد. بنابراین فایلهای صفحه (مانند تصاویر، javascript، CSS) هنوز به HTTPS به روزرسانی نشدهاند.
دقت کنید تمام تصاویر و فایلهای وبسایت شما باید به آدرس //:https اشاره کنند.
مشکل ۳: هنگامی که لینکهای داخلی در HTTPS به روزرسانی نشده باشند
عدم به روزرسانی لینکهای داخلی شما به HTTPS باعث تغییر مسیرهای غیرضروری میشود. همه URLها را به آدرس //:https بازنویسی کنید و کار تمام است.
اشتباه ۴: هنگامی که تگها به https به روزرسانی نشده باشند
دو نوع تگ وجود دارد که ممکن است در وبسایت خود از آن استفاده کنید:
- اپنگراف: Open Graph Tags
- تگ کنونیکال: Canonical Tags
دقت کنید URLهای آنها نیز باید به HTTPS به روزرسانی شوند.
Canonical tag گوگل را متوجه میسازد که معتبرترین صفحه در بین صفحات مشابه یا تکراری کدام صفحه است. اشاره به یک نسخه HTTP قطعا میتواند سیگنال بدی را به گوگل ارسال کند و به احتمال زیاد نادیده گرفته میشود.
آموزش سئو تکنیکال: راهنمای رایگان و صفر تا صد برای شروع
اگر از Open Graph Tags برای بهینهسازی پستهای رسانههای اجتماعی خود استفاده میکنید، باید بدانید که فیسبوک به URL Tags نیاز دارد. آنها نیز باید همانند Canonical URL باشند.
تمام این آدرسها نیز باید به HTTPS تغییر یافته باشند.
اشتباه ۵: هنگامی که تغییر مسیرها (ریدایرکتها) ناموفق باشند
تغییر مسیرها میتوانند فریبنده باشند. موارد زیادی برای اشتباه وجود دارد. از تغییر مسیرهای خراب گرفته تا تغییر مسیرهای حلقهای و زنجیرهای.
خوشبختانه تشخیص این خطاها با استفاده از screaming frog آسان است. کافی است مراحل زیر را دنبال کنید:
- سایت را خزش کنید
- روی منوی ‘Response Codes’ tab & ‘Redirection (3XX)’ کلیک کنید
- مشاهده مقصد تغییر مسیر
- منبع ریدایرکتها را با کلیک بر روی برگه “Inlinks” مشاهده کنید
-
از مسیر زیر خروجی بگیرید: Bulk Export > Response Codes > Client Error (3XX) Inlinks
- برای مشاهده زنجیره ریدایرکت این مراحل را انجام دهید: ‘Reports > Redirects > Redirect Chains & Loops
نتیجهگیری
طبق گزارش گوگل بین ۸۸ تا ۹۹٪ از زمان جستجو در مرورگر chrome صرف وبسایتهای https میشود.
درمورد کیفیت پشتیبانی TLS هنوز چیزهای زیادی وجود دارد که میتوان به آن پرداخت. همانطور که در اینجا آموختید، راهاندازی https با فرایند انتقال به پایان نمیرسد. باید صحت عملکرد بعد از انتقال به https را نیز چک کنید.