1. Що ламається після переходу на https
2. Сервіси використовують API
4. Посилання на сторонні ресурси
5. Доступність сторонніх ресурсів по https
6. Посилання на внутрішні ресурси
7. Додатки використовують API
8. вміст robots.txt
9. вміст sitemap.xml
10. Meta-тег canonical
11. кешування
12. висновки

у статті Переїзд на HTTPS на прикладі retail.ru ми вже говорили порядку дій при переїзді на https. Цього разу розберемо найбільш часті помилки виникають відразу ПІСЛЯ переїзду.

Чому це важливо знати? Тому що нікому не хотілося б після переїзду виявити, що обмін з 1С відвалився, від платіжних систем не доходять повідомлення про оплату замовлень, а веб-сайт не переіндексіруется пошукачем. Ми виписали проблеми, з якими стикалися самі і які бачили у інших.

Що ламається після переходу на https

Обмін з 1С

1С (УТ / УПП) використовує настройки параметрів обміну для з'єднання з сайтом. У них вказується адреса сайту. Якщо настройки невірні, то можна побачити схоже повідомлення "Не вдалося встановити з'єднання з сервером. Авторизація користувача не виконана ". В останніх версіях модуля обміну адреса вказується з протоколом, тобто досить змінити протокол і лихо обминуло.

1С: Управління торгівлею, ред. 11.1.

У старих версіях модуля обміну не передбачено з'єднання по https. Зовсім. Тому або будуть потрібні доопрацювання на стороні 1С, або потрібно залишити скрипт імпорту доступним по HTTP.

Приклад такого виключення (для вставки в .htaccess):

RewriteCond% {SERVER_PORT}! ^ 443 $

RewriteCond% {REQUEST_URI}! ^ / Bitrix / admin / 1c_exchange.php

RewriteRule ^ https: // ваш-сайт% {REQUEST_URI} [R = 301, L]

Сервіси використовують API

Як правило, сайти (особливо інтернет-магазини) інтегровані з безліччю сторонніх сервісів:

• платіжні системи (Яндекс.Касса, IntellectMoney, Web Money),
• служби доставки (СДЕК, ПЕК, DHL),
• лічильники відвідувань (Google Analytics, Яндекс.Метрика),
• соц-мережі та ін.

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

І немає, редирект з http на https на стороні сайту тут не допоможе. На сайт просто не буде приходити повідомлення про оплату замовлень, статус доставки; "Поділитися" і лайки також перестануть працювати.

Посилання на сторонні ресурси

Після переїзду на https ми очікуємо, що браузер покаже - наш сайт безпечний:

Однак, всупереч очікуванням ми можемо побачити це:

Таке повідомлення свідчить про підключення на сторінці ресурсів (зображень, стилів, скриптів, шрифтів і т.д) не по https, а по http. У чому саме проблема браузер може вказати в режимі розробника в консолі:

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

Одна з можливих неприємностей, яка може спіткати - неможливість користувачеві оплатити замовлення прямо на сайті. Деякі платіжні системи підключаються на сторінку за допомогою javascript. Якщо скрипт підключений невірно (по http) - браузер заборонить переходити на сторінку оплати. У такій ситуації найчастіше під загрозою: платіжні системи, служби доставки, карти, лічильники, лайки і шарілкі соц.сетей.

Слід пам'ятати, що контент - це не тільки статичні сторінки і шаблони (!), Але ще і Інфоблоки. Підключення зовнішніх ресурсів може відбуватися в описах елементів Інфоблоки і властивості і т.д.

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

Доступність сторонніх ресурсів по https

Якщо сторонній ресурс (наприклад CDN) доступний по http, зовсім не обов'язково, що він буде доступний і по захищеному протоколу:

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

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

Посилання на внутрішні ресурси

Хоча вказувати абсолютні шляхи на внутрішні ресурси - поганий тон, таке все ж зустрічається. Тому також як і в попередньому пункті - знаходимо все посилання з http: // і замінюємо на https: //. А взагалі, щоб не було проблем з переходом, потрібно відразу посилання ставити як "//".

Наприклад: <img src = "// www. Intervolga. Ru / favicon.ico">

В такому випадку буде використовуватися такий же протокол як у поточного url-а.

Додатки використовують API

У вас є мобільний додаток? Або ваш сайт надає REST API? Не забудьте протестувати це API, оновити документацію і дізнатися - а чи можуть клієнти підключитися по https без проблем? Перевіряти потрібно до переїзду, адже може знадобитися доопрацювання.

вміст robots.txt

Сайт на http і https - для пошукових систем два різних сайту. Щоб повідомити пошуковику, що це два дзеркала одного сайту раніше можна було використовувати директиву Host у файлі robots.txt. Вона каже яке дзеркало головне і повинна з усіх дзеркал вести на одну адресу.

З кінця березня 2018. Переїзд сайту здійснюється за допомогою 301 редиректу (Як в Google).

вміст sitemap.xml

Ще один механізм, який допоможе пошуковику дізнатися про переїзд - файл sitemap.xml. У ньому містяться посилання на сторінки сайту, які потрібно проіндексувати. Після переїзду не забуваємо перестворити sitemap.xml cо посиланнями на https.

Meta-тег canonical

На хороших SEO-оптимізованих сайтах давно налаштований мета-тега rel = 'canonical'. Адреса сторінки в цьому тезі завжди задається із зазначенням протоколу. При типовій реалізації протокол змінюється в налаштуваннях відповідного Інфоблоки. Після переїзду необхідно перевірити всі Інфоблоки і вказати канонічний адресу з протоколом https.

кешування

Ну і як же забути про одвічну проблему "не скинув кеш"? Можна блискуче впоратися з усіма проблемами, які ми перерахували вище, але якщо забути очистити кеш сайту, багато зусилля виявляться марними. Звичайно, у Бітрікс є технологія "Керований кеш", але ви абсолютно впевнені що ваші розробники їй скористалися, роблячи який-небудь нестандартний звіт або складну систему лояльності?

висновки

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

Оцініть статтю: