Як додатково перемістити сайт електронної комерції в HTTPS

У жовтні Google Chrome випустить версію 62, яка попередить відвідувачів сайту з повідомленням "Not Secure", коли вони вводять дані - наприклад, пошук на сайті та реєстрацію на розсилку - на сторінках без HTTPS. Chrome видає попередження "Не захищено" для всіх сторінок HTTP у режимі анонімного перегляду.

Це, безумовно, вплине на переходи електронної торгівлі. Для невеликих магазинів, мій докладне керівництво робить перехід до HTTPS відносно безболісним. Але для великих сайтів, приблизно 50,000 URL-адрес і більше, існує більший ризик, враховуючи пріоритети сканування Googlebot і повільне повторне індексацію. Звукова стратегія полягає в переході на повний HTTPS, а також вимірювання впливу трафіку та продажів.

У цій посаді я поясню, як це зробити.

Google розіслав попередження через консоль пошуку Google на зареєстровані сайти з профілями HTTP. У мене є клієнти, які давно перейшли на повний HTTPS. Але вони все одно отримали попередження.

Google Console нещодавно опублікувала це повідомлення всім зареєстрованим сайтам, вказуючи, що Chrome покаже попередження безпеки, починаючи з жовтня 2017 для сайтів, які не мігрували на HTTPS.

Google Console нещодавно опублікувала це повідомлення всім зареєстрованим сайтам, вказуючи, що Chrome покаже попередження безпеки, починаючи з жовтня 2017 для сайтів, які не мігрували на HTTPS.

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

На момент написання статті, Canary використовує версію 62, яку слід ввести попередження. Але, я не міг отримати попередження "Не безпечно", щоб з'явитися в моїх тестах. Я планую спостерігати за Canary, щоб дізнатися, коли з'являються попередження.

Скористайтеся версією Google Chrome Canary, щоб дізнатися, чи вплине ваш сайт.

Скористайтеся версією Google Chrome Canary, щоб дізнатися, чи вплине ваш сайт.

Я сканував через Національну федерацію роздрібної торгівлі 2017 список провідних традиційних ритейлерів, та знайдене декілька з них не зробили перехід до повного HTTPS все ще, включаючи добре відомі гатунки наприклад AutoZone, Nordstrom, Gap, Publix, Sears, Метро, ​​BJs, QVC, та Saks Fifth Avenue. Затримка зрозуміла з огляду на ризик втрати цінного трафіку пошукової системи під час переїзду.

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

Ось профіль HTTP з консолі пошуку Google для одного клієнта з кількома тисячами сторінок, перенесених на повний HTTPS.

Деякі сайти відчувають швидку повторну індексацію сторінок після переходу на HTTPS.

Деякі сайти відчувають швидку повторну індексацію сторінок після переходу на HTTPS.

Google повторно індексував сторінки HTTPS швидко, приблизно за два тижні. Але інший клієнт, що має більше 1 мільйонів сторінок, бачив набагато повільнішу (і болючішу) переіндексацію. Пройшло приблизно півроку.

Інші сайти можуть переживати тривалий та болісний переіндексацію.

Великі сайти, такі, як цей, що мають більше 1 мільйонів сторінок, можуть переживати тривалий та болісний переіндексацію.

Перший клієнт не бачив негативного впливу на трафік SEO. Другий. Це змусило мене планомірно планувати міграції з високими ставками. Багато сайтів, наприклад Опікун і провідна, поділилися своїм досвідом з кроком.

Мій додатковий план міграції включає три етапи.

  • Виконайте аналіз журналу сервера, щоб визначити, які групи сторінок потрібно перенести. Розташуйте сторінки, які частіше сканують Googlebot, оскільки це дозволить нам швидко вивчити вплив.
  • Інкрементно оновлювати карти перенаправлення та канонічні теги для виконання фактичного переміщення.
  • Відстежуйте прогрес у консолі пошуку Google і в Google Analytics або подібному. Нам потрібно використовувати два профілі (HTTP і HTTPS), щоб забезпечити зниження індексованих сторінок (і трафіку) для профілю HTTP, і відповідне збільшення індексування і трафіку для профілю HTTPS.

Якщо під час кожного розділу рухаються якісь проблеми, ми можемо швидко повернути назад.

Аналіз журналу веб-сервера

Один з підходів, який я успішно застосував для визначення пріоритетів додаткових міграцій, - це почати з сторінок із найменшими значеннями (сторінки без трафіку або посилань), а потім перемістити сторінки з більшим значенням. Такий підхід працює, але для виконання потрібні місяці.

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

Ви можете завантажити файл CSV у Google Таблиці або скористатися Excel для створення зведеної таблиці з URL-адресою сторінки та кількості відвідувань Googlebot. Можна також додати додаткову колонку з категорією сторінки, щоб об'єднати групи найбільш сканованих сторінок.

Ідея полягає в тому, щоб спочатку перемістити найбільш часто скановані сторінки або групи сторінок до HTTPS, тому що ми очікуємо, що їх відносно швидко підбере Google. Ми можемо побачити, який вплив має рух на SEO-трафік, а потім продовжити процес, якщо ми не побачимо жодних проблем.

Перенаправлення та канонічні правила

Я вирішив загальні проблеми міграції в розділі "SEO: Як перенести сайт електронної комерції на HTTPSУ цьому розділі, нижче, я зосереджуся виключно на перенаправленнях і канонічних змінах. Перегляньте попередню статтю, щоб двічі перевірити всі кроки.

Припускаючи, що послідовність перевірки використовує HTTPS за замовчуванням, це зміни (для серверів Apache), щоб примусити весь сайт до HTTPS.

RewriteEngine On # Це дозволить увімкнути можливості перезапису
RewriteCond% {HTTPS}! = On # Це перевіряє, чи не встановлено з'єднання HTTPS RewriteCond% {REQUEST_URI}! (^ /? Checkout /.*) RewriteRule ^ (. *) $ Http: //www.webstore. com / $ 1 [R, L] # Це змушує HTTP, якщо сторінка не знаходиться у послідовності перевірки RewriteCond% {REQUEST_URI} (^ /? checkout /.*) RewriteRule ^ (. *) $ https: //www.webstore .com / $ 1 [R, L] # Це змушує HTTPS для сторінок у послідовності перевірки

Ваші існуючі правила перезапису будуть виглядати приблизно так. Це перекладається на: примусову будь-яку URL-адресу, яка не є частиною процесу перевірки (ідентифікується за /перевіряти) URL-адреса HTTP.

Ми можемо просто розширити це правило, щоб включити інші шаблони груп сторінок. Наприклад, скажімо, ми хочемо перенести категорію жіночого одягу до HTTPS, ми зробимо це.

RewriteEngine On # Це дозволить перезаписувати можливості RewriteCond% {HTTPS}! = На # Це перевіряє, щоб підключення не було вже HTTPS RewriteCond% {REQUEST_URI}! (^ /? Checkout /.* | ^ /? Жіночий одяг) /.*) RewriteRule ^ (. *) $ Http://www.webstore.com/$1 [R, L] # Це змушує HTTP, якщо сторінка не знаходиться у послідовності перевірки або категорії жіночого одягу RewriteCond% {REQUEST_URI } (^ /? checkout /.* | ^ /? жінок-одяг /.*) RewriteRule ^ (. *) $ https://www.webstore.com/$1 [R, L] # Це змушує HTTPS, якщо Сторінка знаходиться у воронці замовлення або категорії жіночого одягу

Ми використовуємо символ регулярного виразу pipe (|), що означає "або" (відповідає цьому чи тому). Ми можемо додати більше груп сторінок шляхом об'єднання (тобто, зв'язування) своїх шаблонів регулярних виразів за допомогою труб.

Я підтвердив, що це працює правильно, використовуючи цей зручний Apache htaccess tester.

Оскільки сторінки оновлюються до HTTPS, вони повинні бути перенаправлені з відповідними канонічними тегами.

Оскільки сторінки оновлюються до HTTPS, вони повинні бути перенаправлені з відповідними канонічними тегами.

Сторінки жіночого одягу перенаправляються на HTTPS, інші сторінки перенаправляються на HTTP.

Коли ми переміщуємо сторінки з HTTP до HTTPS, нам потрібно оновити канонічні теги для відображення нових URL-адрес за замовчуванням. Наприклад https://www.webstore.com/women-clothing повинні мати https://www.webstore.com/women-clothing як канонічний, не http://www.webstore.com/women-clothing or / жіночий одяг.

Відстеження прогресу

Нам потрібно відстежувати індексацію і рівні трафіку SEO до груп сторінок, які ми переміщуємо. В ідеалі, слід також контролювати сканування Googlebot за допомогою свіжих журналів серверів. Перенаправлення та канонічні повідомлення повинні призвести до того, що сторінки HTTP випадуть з індексу та заміняться на відповідні сторінки HTTPS.

Органічний пошуковий трафік можна звузити до групи сторінок, використовуючи опцію "Відповідність RegEx" у Google Analytics розширені фільтри. Це покаже лише трафік до групи сторінок, які ми переміщуємо.

Звужте органічний пошуковий трафік на групу сторінок, використовуючи опцію "Відповідний RegEx" у розширених фільтрах Google Analytics.

Звужте органічний пошуковий трафік на групу сторінок, використовуючи опцію "Відповідний RegEx" у розширених фільтрах Google Analytics.

Щоб відстежувати повторну індексацію, створіть окремий файл Sitemap XML з набором сторінок, які ви мігруєте, і видаліть ці сторінки з основних XML-мапи сайту. Зареєструйте в консолі пошуку Google два набори файлів Sitemap XML: один для профілю HTTP (з використанням URL-адрес HTTP), а інший - для профілю HTTPS (використовуючи URL-адреси HTTPS).

XML-мапи сайту покажуть вам рівні індексування сторінок.

Можна перемикатися між профілями консолі пошуку, щоб побачити HTTP-сторінки, які індексуються, і сторінки HTTPS.

Якщо ви помітили помилки під час переміщення, ви можете швидко відкинути групу проблем і діагностувати проблему перед тим, як продовжити.

Проблеми, які ми зазнали, включають використання інструментів переадресації, наданих платформою електронної комерції (наприклад, інструмент Magento), а не використання функцій перенаправлення веб-сервера.

Більш ніж один клієнт електронної комерції пропустив основні перенаправлення 301 - від не-www до www, або від відсутньої кінцевої слеш до кінцевої слеші - після переходу до HTTPS. Це призвело до створення дубльованого контенту: сайт був доступний після переміщення https://sitename.com і https://www.sitename.com. Іншою поширеною проблемою є численні перенаправлення. Googlebot зазвичай не проскакує за п'ять переадресацій у ланцюжку.

джерело

залишити коментар

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються ваші дані коментарів.