Как да преминете към https: инструкции стъпка по стъпка. Как работи https

През юли 2014 г. Google обяви предимство при класирането на сайтове с правилно инсталиран SSL сертификати. Преобразуваните и защитени със SSL сайтове започнаха да се появяват като HTTPS (hypertext transfer protocol secure) за разлика от по-ранния стандарт HTTP. Така че има допълнително ниво на сигурност, което предотвратява нежелан достъп до съхраняваните данни.

Днес Google, Safari, Firefox и повечето други популярни браузъри изискват този протокол за по-добро класиране, геолокация, въвеждане на данни за кредитни карти и др. Протоколът за сигурност HTTPS също така предпазва уебсайта от нежелани реклами, които досаждат на посетителите с натрапчива, невзрачна информация, понякога съдържаща зловреден софтуер. От октомври 2018 г. Google започна да показва червено предупреждение, когато потребителите въвеждат данни в HTTP страници, или зелено заключване в адресната лента, когато сигурността в HTTPS е наред.

Кратко определение

HTTPS и SSL са видими в URL адресите на уебсайтовете, което се отразява в лентата на браузъра. Наблизо можете да видите и символ на катинар. По този начин съвременните браузъри показват, че потребителят се намира на сайт, който използва SSL криптиране. В някои случаи URL адресът включва името на компанията. Тези знаци показват, че посетителят се намира на сайт, който се отнася сериозно към поверителността. Съкращение от HTTPS Secure Hypertext Transport Protocol. Неговият "брат" HTTP означава същото, но без "secret" в края, и е комуникационен протокол, който обикновено се използва за улесняване на уеб трафика.

Защитената версия използва сертификат SSL (Secure Socket Layer) за установяване на връзка между браузъра и сървъра. Така става ясно как работи HTTPS - всяка обменяна информация се криптира. Криптирането е процес на заместване на обикновена текстова информация, като например потребителски имена и пароли, със случайни числа и букви. Така тя вече не може да бъде разчетена от хора и е по-трудна за разбиране по време на прихващане.

Малко уточнение: SSL не е технически правилен термин, той е променен на TLS (transport layer security) в края на 90-те години. Въпреки това тя все още се използва често при описание на HTTPS процеси.

Първо, какво ви е необходимо за да преминете към информационни технологии за защита на HTTPS информацията е да се закупи подходящ SSL сертификат, който създава криптирана, непробиваема връзка между прозореца на браузъра и уеб сървъра. Съществуват различни видове сертификати, които се различават по цена. Важното е, че всички те работят на един и същ принцип, така че потребителят не получава "повече сигурност" само защото плаща повече.

Съществуват различни набори от функции:

1. Начално ниво на домейна SSL. Те се издават незабавно и изискват само потвърждение по имейл, преди да преминете към HTTPS, предлагат сърфиране в HTTPS със заключване, без задълбочен процес на анализ, само проверка на собствеността на домейна. Идеален вариант за малки компании с ограничен бюджет, които не приемат онлайн плащания.
2. Организационните SSL сертификати изискват по-висока степен на проверка на собствеността на компанията. При този тип сертификат името на компанията и името на домейна се появяват в лентата на браузъра.
3. SSL с разширено валидиране, което ви позволява да използвате "зелената лента на браузъра". Те са по-скъпи от предишните сертификати и включват правна, оперативна и физическа валидация.
4. След получаване на SSL сертификата той трябва да бъде одобрен. Има различни нива на проверка преди издаването на сертификата, Например, за домейн SSL, тя може да бъде издадена веднага, след като собственикът на домейна е потвърдил своя имейл адрес. Ако собственикът на сайта използва споделен хостинг, подайте заявление до доставчика за администриране на сървъра с одобрен сертификат, преди да преминете към HTTPS.

Алгоритъм за миграция към HTTPS:

1. Извършване на пълно резервно копие на сайта. Ако хостингът се управлява от cPanel, можете да използвате вградената функция за архивиране на cpanel. В противен случай се свържете с хостинг компанията, за да разберете дали предлага услуга за управлявано архивиране.
2. Промяна на HTTP връзките на уебсайта към HTTPS. Процедурата зависи от размера на сайта, който определя начина на работа на HTTPS. Ако в сайта има само няколко страници, може да се използва ръчен процес. Ако е налично стотици или дори хиляди страници - използвайте инструменти, които автоматизират процеса, особено ако е хостван на енджина на WordPress.
3. Проверка на библиотеките за код, преди да преминете към HTTPS. Тази стъпка не е задължителна и се прилага при по-сложни сайтове, които използват допълнителен софтуер, като JavaScript и Ajax.
4. Актуализиране на всички външни връзки, сочещи към сайта, от акаунти в социалните мрежи и списъци в авторитетни директории.
5. Създаване на пренасочване към HTTPS 301. Звучи сложно, но всъщност не е. 301 е метод за пренасочване на трафик от една уеб страница към друг URL адрес. Това е важен момент, тъй като ако даден сайт има десетки, стотици или дори хиляди обратни връзки, сочещи към него от други сайтове, те ще сочат към HTTP страници, а класирането в търсачките зависи от количеството и качеството на обратните връзки. Задаването на пренасочване 301 зависи от типа на използвания уеб сървър. Най-популярните видове уеб сървъри са Apache, NGinx и LiteSpeed, а Windows. Преди да преминете към HTTPS При Apache и LiteSpeed трябва да актуализирате файла htaccess, при NGinx - конфигурационния файл на NGinx, а при Windows - уеб.конфигуриране.
6. Ако използвате мрежа за доставка на съдържание (CDN), като например CloudFlare, трябва да синхронизирате SSL с тази система. CDN е глобално разпределена мрежа от сървъри, които съхраняват копия на уеб страници на своите сървъри. Това осигурява не само предимства по отношение на скоростта, но и на сигурността, тъй като може да открива различни модели на зловреден софтуер и да предотвратява компрометирането на сайта.
7. Актуализиране на всички други инструменти и транзакционни имейли, като например имейл маркетинг, автоматизация и генератори на целеви страници. Подгответе списък с тях и потърсете препратки към уеб страници, които са свързани с HTTP, след което ги актуализирайте към HTTPS.
8. Накрая, но не на последно място, за да следвате инструкциите за миграция към HTTPS, трябва да актуализирате акаунтите си в Google Analytics и Search Console. Промяна на URL адреса по подразбиране в Analytics на HTTPS. Нов сайт с HTTPS трябва да бъде добавен в Search Console.

Избягване на капаните на SEO

Chrome предупреждава потребителите, че сайтът не е защитен, когато попълват формуляр, например поле за търсене или регистрация на имейл. Това последно предупреждение, съчетано с предимствата на Google SEO, ускори прехода за много сайтове.

Съществуват многобройни детайли и контролни списъци за инженерната част, но понякога спецификата на SEO може да бъде пренебрегната по време на прехода. Контролен списък HTTP за HTTPS, който се фокусира само върху въпросите на SEO: планиране, миграция и мониторинг след миграцията.

С Keylime Toolbox Query Analytics можете да обобщавате данни за HTTP и HTTP Secure заявки от Google Search Console и да наблюдавате тенденциите в процентите на кликване, класирането, импресиите по време и в обобщен вид, по заявки и по категории. Keylime Toolbox Crawl Analytics осигурява ежедневен анализ на дневника, за да следи обхождането на Googlebot, да преценява колко време ще отнеме пълното обхождане и повторното индексиране и да идентифицира всякакви проблеми. Ако сайтът е голям и нормалното обхождане е неефективно, обмислете въвеждането на специални елементи за ефективност на обхождането преди миграцията.

Персонализиране на функциите за преход

При преминаване към пренасочвания конфигурирайте следните параметри. Ръководство за преминаване от HTTP към HTTPS:

1. 301 пренасочване на HTTP адреси към HTTPS-URL. Разрешаване на всички съществуващи правила, доколкото е възможно. Google ще обхожда само до 5 пренасочвания в една верига.
2. Актуализиране на всички вътрешни връзки към HTTPS URL адреси.
3. Актуализиране на метаданни и структурирани маркировки.
4. Уверете се, че всички ресурси са преместени към HTTPS и връзките са актуализирани в изходния код на страницата.
5. Проверка на свойството HTTPS в конзолата за търсене на Google.
6. Създаване на набор от свойства, които комбинират HTTP и HTTPS за целите на мониторинга.
7. Конфигуриране на настройките за обработка на HTTPS домейн в Google Search Console в съответствие с настройката HTTPS.
8. Установяване на международно насочване.
9. Задаване на скоростта на пълзене.
10. Уверете се, че файлът HTTPS robots.txt има същото съдържание като това, посочено преди това за HTTP, и не забранява всички.
11. Уверете се, че HTTPS страниците нямат атрибути "meta noindex".
12. Уверете се, че са зададени тагове за уеб анализ и други тагове на трети страни.
13. Изпращайте XML Sitemap за URL адреси на HTTPS и не блокирайте HTTP URL адреси с роботи.txt.
14. Наблюдавайте трафика от нормалното търсене в уеб анализите, за да се уверите, че той е последователен.
15. Проследяване на класиранията и други специфични за SEO данни в Google Search Console.
16. Проверете ръчно показването на резултатите от търсенето, за да се уверите, че всичко изглежда правилно, тъй като HTTPS URL адресите се индексират.

Сканиране на робота на Google

Данните за проследяване на начина, по който роботът на Google сканира HTTP и HTTPS, кои URL адреси са сканирани и какви кодове за отговор получава, са достъпни само ако използвате Crawl Analytics, който изтегля регистрационните файлове на сървъра за обработка. Изтегля се пълен списък на предоставените от Google грешки при сканиране както за HTTP, така и за HTTPS, както и данни за източника на връзката за всяка грешка.

Извършва проследяване на съвкупните класирания по HTTP и HTTPS и трафика с течение на времето за маркови и немаркови заявки, както и други данни за SEO, като например индивидуални и съвкупни проценти на кликване и общия брой кликвания, при които се появява сайтът

Ако сайтът е голям и обхождането е неефективно, може да отнеме известно време на Google да сканира отново всички HTTP URL адреси и да ги замени с HTTPS версии в индекса, за да ускори процеса. Регистрационните файлове са чудесен източник за идентифициране на проблеми с производителността. Въпреки че Google твърди, че обработва потока PageRank по един и същи начин за 301 и 302, тези пренасочвания все пак се обработват по различен начин. Тъй като 302 е технически "временен", Google продължава да индексира целевия URL 302. При 301 пренасочване Google премахва URL адреса на пренасочване от индекса и индексира само целевия 301 URL адрес.

Консолидиране на правилата за пренасочване

Googlebot извършва само до 5 пренасочвания, а тъй като URL адресите се променят с течение на времето и се добавят правила за канонизация, верижните пренасочвания стават обичайни. Те обаче забавят зареждането на страниците, особено на мобилни устройства.

В много случаи пренасочванията HTTP/HTTPS и www/non-www се извършват на ниво сървър, а всички останали - на ниво приложение. В този случай идеалният сценарий е да се използва един 301 на ниво сървър, за да се отчитат и HTTP/HTTPS.

Последното пренасочване към HTTPS ще включва тези правила:

1. От старите модели на URL към настоящите, всички стари правила се актуализират с настоящите крайни цели. Нормализиране на регистъра, например от пример.Твърдите дискове, независимо от техния избор, са предназначени за постоянно съхранение на данни.com/page1 и крайната наклонена черта, напр. пример.com/page1 към example.com/page1/. В този пример.com/Page1 ще пренасочи 301 директно към example.com/page1/ един цикъл HTTPS и www.
2. Прегледайте всички стари правила, актуализирайте ги и ги консолидирайте, като се уверите, че всички са настроени на 301, а не на 302. URL адресите, които се пренасочват към 302, могат да останат индексирани, което води до непредсказуеми елементи на показване в резултатите от търсенето. Те могат да показват не само грешен URL адрес, но и други нежелани действия. Например, ако метаданни, като например връзки към уебсайтове, са свързани с текущия URL адрес, а старият се показва в резултатите от търсенето, то допълнителните връзки няма да се показват.
3. Актуализиране на всички вътрешни връзки до канонични URL адреси, което е полезно да се извърши, тъй като пренасочванията увеличават времето за зареждане на страницата, особено на мобилни устройства. В идеалния случай вътрешните връзки трябва да са абсолютни, а не относителни, и да се актуализират към HTTPS URL адреси.
4. Използвайте относителни, а не абсолютни препратки, което ще премахне трябва да се актуализира вътрешен. Това е нормално, но не е идеален и се дължи на факта, че вътрешните връзки са силни канонични сигнали за търсачки, така че, ако някой URL адрес е конфигуриран неправилно да не се пренасочва, тогава сайтът по невнимание се дублира на поддомейн или се премахва. Всички връзки на тези страници ще бъдат към неканонични версии на.

В повечето случаи не е необходимо да се извършва много работа за актуализиране на вътрешните връзки. Те често могат да бъдат актуализирани чрез настройки на конфигурацията, програмно или наведнъж чрез скрипт.

Актуализиране на метаданни и структурирани маркировки

Когато се актуализират стойностите на каноничните атрибути на HTTPS URL адреси, ако пренасочванията са 301 от HTTP към HTTPS, но HTTPS URL адресите имат канонични атрибути за HTTP, Google ще види безкраен цикъл, което ще доведе до непредсказуеми резултати при индексирането. За отстраняване на повредата ще е необходимо:

1. За да превключите сайта от HTTP към HTTPS, актуализирайте стойностите на атрибутите Номериране на страници За HTTPS URL адреси.
2. Актуализиране на атрибута hreflang за HTTPS URL адреси.
3. Актуализиране на стойностите на атрибутите, ако се използват за отделни мобилни URL адреси в HTTPS-URL.
4. Актуализиране на структурирани маркировки, като например видеоклипове, въртележки и поле за търсене на връзки към сайта, на HTTPS URL адреси.
5. Уверете се, че всички ресурси са прехвърлени към HTTPS. Всички ресурси, използвани от HTTPS страници, трябва да се обслужват от HTTPS. Това включва елементи като изображения, JavaScript файлове и CSS.
6. Актуализиране на социалните плъгини, рекламните призиви и т.н.
7. Използване на инструментите на Google за търсене на "смесено съдържание" в даден сайт.

Настройване на конзолата за търсене

За да конфигурирате конзолата за търсене, създайте набор от свойства, който съдържа както HTTP, така и HTTPS версии на домейна, който ще наблюдавате. Алгоритъм за последователни действия:

1. Конфигуриране на конфигурацията за обработка на параметри за HTTPS версията на домейна в конзолата за търсене на Google.
2. Задайте международно насочване, ако е приложимо, за да съответства на това, което е зададено за HTTP.
3. Актуализиране на честотата на обхождане, ако е зададена за HTTP.
4. Качване на всички отменени файлове, които са качени за HTTP.
5. Задаване на предпочитан домейн.
6. Задаване на протокол за изключване на роботи за HTTP и HTTPS.
7. Осигуряване на файл HTTP robots.txt пренасочвания или 404.
8. Уверете се, че файлът HTTPS robots.Файлът txt има същото съдържание като предишния HTTP, с изключение на връзката към картата на сайта.
9. Уверете се, че HTTPS страниците нямат атрибут meta noindex.
10. Уверете се, че таговете на Web Analytics (и други) са все още на място

В много случаи сайтът ще продължи да използва същите тагове за уеб анализ, напр. Google Analytics property id. Но ако това се промени, уверете се, че страниците на сайта са актуализирани. Също така се уверете, че изходният код, съдържащ таговете, не е премахнат от страниците по време на миграцията. Можете да използвате инструмент на трета страна за проверка на етикетите или да настроите скенер, например Screaming Frog, който да ги проверява.

Ако XML Sitemaps са добавени в Google Search Console, можете да използвате отчети за проследяване на намаляващите индекси. Започнете да обхождате ботовете на Google през HTTPS URL адреси, когато те са в XML картата на сайта. Възможно е да наблюдавате увеличаването на индексирането с помощта на XML отчети за индексиране. Винаги създавайте изчерпателни и канонични XML карти на сайта не само за целите на преминаването от HTTP към HTTPS.

Монитор на конзолата за търсене

Необходимо е да подадете XML карта на сайта за URL адреси в HTTPS и да оставите съществуващата XML карта на сайта за HTTP. Това ще доведе до намаляване на индексирането за свойството HTTP и увеличаване на индексирането за свойството HTTPS.

Всички URL адреси в HTTP картата на сайта трябва да имат код на състоянието 301, а индексирането трябва да намалява с течение на времето. Всички URL адреси в HTTPS картата на сайта трябва да имат код на състоянието 200, а индексирането с течение на времето трябва да увеличаване на. Този процес може да отнеме известно време и може да се окаже, че някои HTTP URL адреси все още се индексират месеци по-късно.

Повечето Общи причини това:

1. HTTP URL адресите се блокират от роботите.txt, така че Googlebot не може да сканира пренасочвания и са частично индексирани.
2. HTTP URL адресите са "неканонични" и не се обхождат много често.
3. HTTP URL адресите не връщат 301, а връщат 302 или грешка.

Съвети за отстраняване на неизправности

За съжаление, следването на инструкциите стъпка по стъпка и преминаването към HTTPS е доста сложен процес и потребителят трябва да разбере с какво се занимава.

Основен видове повреди, когато преход:

1. Най-честите проблеми, които се срещат, след като сайтът премине към HTTPS, са предупреждения за смесено съдържание. Това се случва, когато браузърът открие опасни връзки на друга защитена страница. Обикновено става въпрос за актуализиране на връзките към библиотеките на jquery, персонализираните шрифтове или подобни техните HTTPS версии. Потребителят трябва да внимава, когато сканира сайта си, преди да го публикува, и ако се появят такива предупреждения, задължително да провери източниците, които ги предизвикват.
2. Преминаването от HTTP към HTTPS може да се отрази негативно на класирането, въпреки че това обикновено е само временно. Ако настроите 301 пренасочвания, тя се справя само с 90-99% от масата на връзките. Ето защо класирането може да се понижи в началото. Въпреки това те трябва да се увеличават с течение на времето и да ви бъдат от полза в дългосрочен план.
3. Ако установите, че някои URL адреси продължават да се индексират месеци по-късно, но отчетите за анализ на търсенето в Google Search Console не показват никакви кликвания върху HTTP свойството, може би не е необходимо да проучвате този проблем. URL адресите не се класират за заявки и не предизвикват проблеми. Ако обаче има кликвания върху свойството HTTP, URL адресите се класират за заявки.
4. Най-лесният начин да започнете разследването е да прегледате дневника на сървъра, за да видите какво точно получава роботът на Google, когато обхожда. В Excel файловете на дневника в детайли включват таб, в който са изброени всички URL адреси с код на отговор 200, всички URL адреси с код на отговор 302 и т.н.
5. Възможно е да сканирате сайта с инструмент като Screaming Frog, за да получите списък с URL адреси, които връщат 200, блокирани от роботи.txt. Можете също така да разгледате конзолата за търсене на Google> Сканиране> роботи.txt Тестер за свойствата на HTTP, за да видите дали Google вижда файла robots.txt и ако е така, дали блокира някакви URL адреси.

Други капани, които не са свързани с SEO

Съществуват и други възможни проблеми за сайтовете, които преминават към HTTPS:

1. Потенциално намаляване на приходите от AdSense. В миналото спадът на приходите от Adsense се дължеше на голям брой несъвместими с HTTPS реклами. Важно е да се отбележи, че ако потребителят премине от HTTP към HTTPS, той трябва да актуализира кода на AdSense, в противен случай ще получи описаните по-горе проблеми със съдържанието.
2. Не е необичайно даден сайт да загуби всичките си споделяния в социалните мрежи, когато премине към HTTPS. Дори фантастична статия, която събира десетки хиляди харесвания във Facebook, може да се окаже нулева. В документацията на Facebook е обяснено заобикаляне на този проблем, което включва задаване на метатагове og: url, за да се посочи старата http-URL. В него обаче се казва, че това работи само ако старият URL адрес върне отговор от 200. Ако пренасочите http страниците към https страниците, тогава "старите" страници ще връщат 301 вместо 200.
3. Преминаването към HTTPS може да накара Google да преоцени сайта по отношение на качеството. Той е най-големият проблем по време на прехода и може да означава, че всички страници на сайта ще получат нова оценка за качество. Възможно е тези трикове и вратички, които са били използвани преди, вече да не работят след преминаването към HTTPS, което води до намаляване на трафика след преминаването към HTTPS.
4. Файловете на картата на сайта трябва да се актуализират. Уверете се, че е създадена и нова карта на сайта, преди да преминете към нея.
5. Файлът за отказ от права трябва да бъде качен в HTTPS.
6. Google все още третира HTTPS и HTTP версиите на сайта като различни и ако използвате Google Search Console, ще трябва да създадете ново свойство за HTTPS версията. Ако потребителят има файл за прекъсване на връзката, трябва да го качите в HTTPS версията.
7. Уверяване, че сертификатът не е изтекъл. Ако сайтът работи с HTTPS и срокът на валидност на сертификата за сигурност изтича, когато Google се опита да изпрати посетители към сайта, те ще получат голямо предупреждение на цял екран, което определено ще отблъсне хората.

Осигуряването на трафик е един от най-важните въпроси за всеки собственик на уебсайт. В допълнение към прехвърлянето на доверието, процесът печели от увеличената скорост и подобрената SEO оптимизация. Това е чудесна инвестиция за бъдещето, тъй като мрежата се развива в тази посока. Както беше споменато, Google счита използването на SSL за положителен фактор за класиране, така че ако даден потребител премести своя уебсайт към HTTPS, това всъщност ще го направи по-привлекателен. Мислете за, че след с такъв убедителен аргумент потребителят вече няма да се замисля дали да премине към HTTPS и защо да вдига толкова голям шум.