Правильно налаштований 301 редирект передає на нову адресу майже всю вагу старої, тому позиції після переїзду просідають тимчасово, зазвичай на два-чотири тижні, і повертаються. Трафік втрачають не через сам редирект, а через помилки навколо нього: усе перенаправили на головну, вийшли ланцюжки з трьох стрибків, у меню лишились старі посилання, а в sitemap старі URL. Нижче розбираємо, чим 301 відрізняється від 302 і 308, у яких випадках він потрібен, як прописати правила в .htaccess та nginx і як переконатись, що все спрацювало.
Код відповіді сервера каже браузеру і пошуковику, що сторінка переїхала, і як до цього ставитись. Для SEO принципова різниця між постійним і тимчасовим переїздом: у першому випадку Google поступово замінює стару адресу в індексі на нову, у другому продовжує тримати стару і чекає, коли вона повернеться.
| Код | Що означає | Метод запиту | Коли доречний |
|---|---|---|---|
| 301 | Постійний переїзд | Може змінитись на GET | Зміна URL, домену, злиття сторінок, перехід на https |
| 302 | Тимчасове перенаправлення | Може змінитись на GET | Акції, A/B-тести, сторінка тимчасово недоступна |
| 307 | Тимчасове, метод зберігається | Не змінюється | Форми та API, де POST має лишитись POST |
| 308 | Постійне, метод зберігається | Не змінюється | Те саме, що 301, але для POST-запитів |
| meta refresh | Перенаправлення на рівні HTML-сторінки | Не застосовується | Лише без доступу до сервера; Google обробляє повільніше |
Для більшості сайтів вибір зводиться до двох варіантів: 301 назавжди, 302 на кілька днів. Дилема «302 чи 301» вирішується одним питанням: чи повернеться стара адреса. Якщо ні, ставте 301. Google давно підтверджує, що обидва коди передають PageRank, але з 302 пошуковик довше тримає в індексі стару сторінку і може взагалі не переключитись на нову. Ми в Query не раз бачили сайти, де після редизайну рік стояв 302, а в пошуку далі висіли старі URL, які на кліку віддавали 404.
Meta refresh і JavaScript-перенаправлення Google теж розуміє, але обробляє повільніше і не завжди. Це запасний варіант для конструкторів сайтів без доступу до конфігурації сервера, не основний інструмент.
Сам рядок у конфігурації пишеться за хвилину. Позиції втрачають на підготовці, тому послідовність має значення.
На Apache редиректи живуть у файлі .htaccess у корені сайту, на nginx у конфігурації сервера (nginx.conf або файл сайту в sites-available). Після правок nginx треба перезавантажити командою nginx -s reload, Apache підхоплює .htaccess одразу.
Одна сторінка на нову адресу:
Redirect 301 /stara-storinka/ https://site.ua/nova-storinka/Увесь сайт із http на https і на версію без www одним правилом:
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^(.*)$ https://site.ua/$1 [R=301,L]Переїзд на новий домен зі збереженням шляхів:
RewriteCond %{HTTP_HOST} ^(www\.)?old-site\.ua$ [NC]
RewriteRule ^(.*)$ https://new-site.ua/$1 [R=301,L]Окрема сторінка:
location = /stara-storinka/ { return 301 https://site.ua/nova-storinka/; }Увесь домен, http і www разом:
server {
listen 80;
server_name old-site.ua www.old-site.ua;
return 301 https://new-site.ua$request_uri;
}В nginx правила через return 301 виконуються швидше за rewrite, і саме їх варто брати для масових переїздів. Для WordPress та інших CMS є плагіни редиректів, але для сотень адрес правило на рівні сервера надійніше і не навантажує PHP на кожному запиті.
Найшвидший спосіб: у терміналі виконати curl -I https://old-site.ua/stara-storinka/. У відповіді має бути рядок HTTP/2 301 і заголовок location: із кінцевою адресою. Якщо за першим 301 іде ще один 301 або 302, це ланцюжок, і його треба скоротити до одного стрибка. Команда curl -IL покаже весь ланцюжок одразу.
Для масової перевірки прогоніть старий список URL через Screaming Frog у режимі List: він покаже код відповіді, кінцеву адресу і кількість стрибків для кожного рядка. Безкоштовних онлайн-чекерів редиректів теж вистачає, для десятка адрес їх достатньо.
У Search Console дивіться два звіти. «Сторінки» (індексування) покаже, чи не зависли старі адреси в категорії «Сторінка з переадресацією» без індексації нової. «Ефективність» через два-три тижні має показати, що кліки з нових адрес відновились до рівня старих. Інструмент перевірки URL дає змогу окремо подивитись, як Googlebot бачить конкретну адресу і яку сторінку вважає канонічною.
Google рекомендує тримати 301 редиректи щонайменше рік: приблизно стільки потрібно, щоб пошуковик переобійшов усі старі адреси, переніс сигнали і перестав на них повертатись. На практиці ми радимо не прибирати їх узагалі, поки живе старий домен або поки на старі адреси є переходи. Зовнішні посилання з інших сайтів ніхто не переписуватиме, і кожне з них через рік так само впиратиметься в стару адресу.
Виняток: технічні правила, що створюють навантаження або конфліктують із новою структурою. Їх переглядають через рік за серверними логами: якщо на адресу ніхто не заходив 12 місяців, правило можна прибрати без наслідків.
robots.txt, і вага передається в нікуди.Якщо на сайті сотні адрес і немає розробника, який знає конфігурацію сервера, безпечніше віддати переїзд у роботи з технічної доробки сайту: карта редиректів, серверні правила і перевірка після запуску там ідуть одним пакетом.
curl -I на відсутність ланцюжків.
.jpg "Структура інтернет-магазину: як побудувати каталог, до якого доходять за 3 кліки")
.jpg "Інтерфейс мобільного застосунку: принципи, етапи розробки та типові помилки")
.jpg "Навіщо потрібні метатеги на сайті: Title, Description, H1 і як їх оптимізувати")
