SEO перевірки для виконання при переході на SSL на веб-сайті готелю

1. Коли SSL помиляється
2. SSL Check # 1: Перенаправлення
3. SSL Check # 2: Канонічні теги
4. SSL Check # 3: внутрішні посилання
5. Перевірка SSL # 4: консоль пошуку
6. Перевірка SSL # 5: Google Analytics
7. Перевірка SSL # 6: мапи XML
8. SSL Check # 7: Неправильний сертифікат

Google був протягом деякого часу всі веб-сайти використовують SSL (Шар Secure Sockets Layer), щоб забезпечити більш високий рівень безпеки в Інтернеті. Більше половини веб-сайтів в Інтернеті Ви вже зробили це, найяскравішим результатом є те, що URL-адреса сайту тепер читає https: // замість звичайного http: //.

Для сайтів, які ще не перейшли, Google оголосив, що почне показувати Повідомлення "Цей веб-сайт не є безпечним" на будь-якому сайті, який має форму введення даних, навіть якщо це просто форма форми контакту або форма підписки на інформаційний бюлетень.

Знімок екрана показує тип попереджувального повідомлення, яке Google почне показувати на незахищених сайтах.

Завдяки підтримці веб-оновлень Google завжди має трохи опору ( див. Google AMP ), але в цьому випадку SSL має сенс для більшості веб-сайтів і, як правило, є виграш / виграш для споживачів і підприємств. Користувачі вашого сайту відчувають себе в безпеці, особливо коли йдеться про введення конфіденційної інформації через ваш сайт. Що стосується вашого готелю, він отримає невелике підвищення SEO, а також, ймовірно, підвищення рейтингу конверсії в той же час.

Коли SSL помиляється

Про це написано багато статей як реалізувати безпеку SSL на веб-сайті Особливо це стосується SEO-впливів, особливо для тих готелів, які вже мають потужне веб-присутність. Зроблено неправильно, ви ризикуєте втратити органічні пошукові рейтинги, які ви працювали над тим, щоб збільшуватися протягом багатьох років, що в кінцевому рахунку зменшить кількість прямих замовлень через ваш веб-сайт. Нижче наведено кілька способів перевірити наявність проблем із вашою реалізацією SSL або ознаки попередження про те, що перехід до SSL може не мати бажаного впливу.

Падіння органічного трафіку та пошукового рейтингу

Перший підказковий знак, що щось не зовсім правильно з налаштуванням SSL, буде, коли ви помітите, що органічний трафік зменшується, коли він не повинен бути (наприклад, він зменшується, незважаючи на сезонні тенденції). Якщо ви помітили зменшення трафіку, спробуйте визначити, де органічний трафік знизився (на які цільові сторінки вплинули). Повинна бути можливість діагностувати, яка сторінка спричиняє втрату трафіку, яка потім повинна дозволити вам перевірити органічні пошукові рейтинги (якщо ви їх відстежуєте, які ви повинні бути). Можливо, ви залишили кілька позицій для ключових пошукових термінів, що призводить до меншої кількості відвідувань.

Якщо органічний трафік дійсно зменшиться з перемикача на SSL, то вам доведеться пройти такі важливі перевірки SEO, які були грубо перелічені в порядку пріоритету:

SSL Check # 1: Перенаправлення

Перш ніж запускати SSL, потрібно просканувати ваш поточний сайт і побудувати файл перенаправлення, який потім буде реалізовано на сервері в момент запуску. Зазвичай використовується правило, яке перетворює будь-яку раніше запитану URL-адресу та завантажує SSL-версію, але це не завжди можливо в залежності від вашого сервера та середовища хостингу.

Приклад файлу htaccess для автоматично створених переадресацій:
RewriteEngine On
Приклад RewriteCond% {HTTP_HOST} ^. .Com [NC]
RewriteCond% {SERVER_PORT} 80
RewriteRule ^ (. *) $ Https://www.example.com/$1 [R, L]

* Переконайтеся, що замінити приклад .com з ім'ям домену, який ви намагаєтеся застосувати до https. Крім того, потрібно замінити www.example.com фактичним доменним ім'ям ( джерело ).

Якщо вищезгадане неможливе, вам може знадобитися створити вручну файл htaccess, що містить статичні перенаправлення. Сам метод не настільки важливий, як переконання, що були реалізовані постійні перенаправлення (301), що призводить до переходу людей зі старих не-SSL-сторінок на нові сторінки SSL. Якщо перенаправлення 301 неможливі, то JavaScript (або мета-перенаправлення) має бути останньою можливістю.

Щоб перевірити, чи це працює на вашому веб-сайті, просто спробуйте відвідати стару версію будь-якої сторінки веб-сайту та перевірте, чи ви перенаправлені на версію SSL. Щоб продовжити це, встановіть " Шлях переадресації »У Google Chrome і перевірте, чи відображається перенаправлення 301.

Знімок екрана з перенаправленням 301 для готелю Surrey під час доступу до їх старих URI не-SSL (http://www.thesurrey.com/)

Не забувайте, що не-веб-сторінки також повинні бути перенаправлені. Це включає в себе будь-які ресурси, розміщені на вашому сайті (наприклад, PDF-файли, самостійно розміщені відео) і зображення.

Наявність 301 переспрямувань є невід'ємною частиною перемикача SSL, оскільки він повідомляє пошуковим системам, що веб-сайт переміщено в іншому місці.

SSL Check # 2: Канонічні теги

У той час як перенаправлення є необхідним для пошукових систем, канонічні теги є лише директивою. Це не означає, що вони не важливі. Канонічна мітка інформує пошукові системи, яка версія URI є кращою в тих випадках, коли це не зрозуміло.

По суті, якщо існують дві версії веб-сторінок з подібним вмістом, але різними структурами URI, канонічний тег повідомляє пошуковим системам, яку версію ви хочете індексувати. Без цього подібні сторінки конкуруватимуть між собою для пошуку.

Під час розгортання SSL на веб-сайті готелю потрібно переконатися, що тепер канонічний тег посилається на SSL-версію вашої URL-адреси. Речі, які слід перевірити, включають в себе забезпечення того, щоб канонічні теги посилалися на абсолютний URI, а не на відносний URI.

Скріншот, що показує канонічний тег готелю Surrey, посилаючись на не-SSL URI, незважаючи на те, що він живий на SSL (що призведе до виникнення проблем, якщо не буде вирішено - див. Нижче!)Фірмовий пошук у Google показує стару URL-адресу домашньої сторінки, яка не є SSL, але все ще індексована, ймовірно, є результатом неправильного налаштування канонічного тегу (порівняйте URI з відображеним результатом TripAdvisor).

Ви можете використовувати подібний інструмент Кричала жаба, щоб перевірити канонічні теги навалом на своєму веб-сайті.

SSL Check # 3: внутрішні посилання

Зробивши всю важку роботу з розгортання SSL, можна подумати, що останнє місце, яке ви очікуєте забути оновити, - це ваш власний веб-сайт. Але багато сайтів забувають оновлювати свої внутрішні посилання, які все ще вказують на стару не-SSL версію їх URI.

Це, швидше за все, не вплине на продуктивність SEO занадто багато, але це все ще має бути вирішене. В іншому випадку ви викликаєте непотрібну пропускну здатність на веб-хостингу, для сканера пошукової системи та більш повільного перегляду для користувача, все з-за можливого переадресації. Знову Програмне забезпечення сканера крику жаби можна використовувати для легкого визначення цих типів проблем.

На цьому етапі варто також оновити будь-які платформи, що належать онлайн, де ви посилаєтеся на веб-сайт готелю, наприклад, профілі соціальних медіа, щоб переконатися, що вони також посилаються на версію вашого сайту SSL.

Перевірка SSL # 4: консоль пошуку

У консолі пошуку Google потрібно налаштувати нові властивості для нових варіантів URL, що означає наявність обох https://www.hotelname.com/ та https://hotelname.com об'єктів. Це дає змогу відстежувати органічну ефективність пошуку та вносити зміни до органічної налаштування. На цьому етапі має сенс створити групу, де ви зможете зберегти всі властивості, що належать вашому готелю, в одному місці.

Налаштування набору властивостей у консолі пошуку дозволяє переглядати продуктивність всіх існуючих варіантів сайтів.

Коли все налаштовано для вашого нового сайту SSL, ви зможете отримати доступ до звітів про помилки сканування, виконувати вибірки та рендери, подавати нові Sitemap XML, а також ряд інших важливих завдань, орієнтованих на SEO.

Перевірка SSL # 5: Google Analytics

Хоча це не завжди є важливою частиною налаштування SSL, має сенс оновити будь-які засоби відстеження Analytics для посилання на новий URI. Це може означати, що використовується в Google Analytics і менеджері тегів, або в залежності від використовуваного програмного забезпечення для відстеження. Перевірте це налаштування та переконайтеся, що дані у профілях протікають так, як очікується, особливо будь-яку інформацію електронної комерції.

Перевірка SSL # 6: мапи XML

Ще однією легко пропущеною задачею SEO під час розгортання SSL є повторне створення та повторне подання будь-яких XML мап сайтів. Їм потрібно буде посилатися на ваші нові URI, тому використовуйте інструмент, як Screaming Frog, щоб відновити і завантажити на свій сайт. Потім знову подайте заявку через консоль пошуку Google, інструменти для веб-майстрів Bing, Яндекс, Baidu та інші використовувані платформи.

Має сенс оновити файл robots.txt для посилань на новий XML-файл теж, лише у випадку, якщо він посилається на старий.

SSL Check # 7: Неправильний сертифікат

На цьому етапі не заважає веб-розробнику перевіряти все, що стосується сертифіката безпеки SSL, переглянувши всі наведені вище конкретні завдання SEO. Ніколи не завадить перевірити налаштування. Також можна легко перевіряти наявність проблем, переглядаючи їх у Google Chrome або використовуючи веб-інструмент, наприклад Відсутній замок .

Відсутній замок буде перевіряти ваш сайт на небезпечні сторінки - життєво важливі для сайтів, які повинні бути на SSL

Ви можете швидко перевірити безпеку свого веб-сайту в Google Chrome, натиснувши Ctrl + Shift + I на клавіатурі, щоб відкрити меню "Перевірити елемент", а потім вибрати вкладку Безпека.