Як зробити безсерверні редиректи за допомогою Cloudflare Workers: покроковий гайд для SEO

Використання Cloudflare Workers для безсерверних редиректів означає перехоплення запиту користувача на мережі Cloudflare edge без звернення до оригінального сервера, з подальшою віддачею відповіді із статусом 301, 302 або умовним редиректом. Завдяки такому підходу можна швидко та масштабовано створювати редиректи за доменом, URL-шляхом, країною, пристроєм, мовою, параметрами кампанії або відповідністю старої сторінки, не змінюючи налаштування веб-сервера. Це ідеальне рішення для SEO-переїздів, зміни домену, маршрутизації рекламних лендингів та управління декількома сайтами з низькою затримкою, централізованим контролем і простим обслуговуванням.

Традиційні редиректи зазвичай налаштовують через Apache .htaccess, Nginx server block, код додатку або хостинг-панель. Ці методи залишаються актуальними, проте для сайтів з високим трафіком, команд, які керують кількома доменами, або проєктів із динамічним прийняттям рішень залежно від геолокації Cloudflare Workers пропонують більш гнучкий рівень управління. Логіка редиректів виконується у найближчому до користувача дата-центрі Cloudflare, що знижує навантаження на origin-сервер і зменшує ризики пов’язані з помилковими правилами на сервері, які можуть впливати на продуктивність і викликати збої.

У цьому посібнику ви знайдете приклади налаштування базового 301 редиректу через Cloudflare Workers, а також складніші сценарії: редиректи за шляхом, параметрами запиту, країною, мобільними пристроями і масові редиректи. Ми також розглянемо, коли для SEO краще використовувати 301 або 302, як тестувати редиректи, а також які перевірки домену, SSL та хостингу варто зробити на платформі Hostragons. Для управління доменом радимо звернутися до Реєстрація домену та управління DNS, для безпечного з’єднання до рішення для сертифікатів SSL, а для оптимальної продуктивності – до Пакети веб-хостингу.

Що таке Cloudflare Workers і чому їх варто використовувати для редиректів?

Cloudflare Workers – це безсерверна платформа, яка дозволяє запускати JavaScript-код на краях мережі Cloudflare. Безсерверність не означає відсутність серверів, а лише те, що вам не потрібно керувати ними – масштабування, оновлення ОС і ресурси обробляються автоматично. Коли користувач надсилає запит до вашого сайту, Worker обробляє його на edge, виконує ваші правила і, за потреби, виконує редирект на іншу адресу.

Основна перевага використання Workers для редиректів – високий рівень контролю. Ви можете не лише порівнювати URL, а й читати заголовки запиту, країну користувача, шлях, параметри запиту, інформацію про user-agent і хост. Наприклад, можна назавжди перенаправити стару сторінку /produkty/hosting на /web-hosting, відправити користувачів з-за меж України на англомовний підкаталог або направити трафік із певним параметром кампанії на спеціальний лендинг.

Такий підхід спрощує і прискорює співпрацю між SEO-фахівцями та технічними командами. Уявіть, що потрібно перенести 450 URL зі старого сайту на новий. Замість редагування конфігураційних файлів сервера, розгортання змін і ризику відкату, ви можете керувати картою редиректів у Worker або зовнішньому сховищі KV. Це робить процес публікації, тестування та повернення більш контрольованим і безпечним.

Відмінності між редиректами на сервері та через Cloudflare Workers

Для кожного проєкту немає універсального рішення. Для невеликого сайту з кількома 301 редиректами може вистачити стандартних інструментів у панелі хостингу. Але якщо логіка складна, трафік великий, доменів багато або потрібна швидка адаптація, Workers будуть ефективнішими. Нижче таблиця з ключовими відмінностями для допомоги у виборі:

Просте правило: якщо у вас мало редиректів, прості умови і є доступ до сервера, класичні методи підійдуть. Якщо ж редиректи потрібні для SEO-міграції, географічного розподілу, A/B тестування або мультидоменності – обирайте Cloudflare Workers.

Що потрібно підготувати перед початком

Щоб уникнути помилок, перед налаштуванням редиректів через Cloudflare Workers потрібно виконати низку технічних кроків. Перш за все, ваш домен має бути підключений до Cloudflare, а DNS-записи мають бути коректно налаштовані. Якщо Cloudflare proxy (помаранчева хмара) не активований для DNS-записів, Worker не зможе перехоплювати трафік, і редиректи не спрацюють як очікується. Тож перевірте статус proxy для кожного хоста, де плануєте редиректи.

• Обліковий запис у Cloudflare і активний домен для редиректів.
• Правильні DNS-записи типу A, CNAME або інші, що вказують на хостинг.
• Активований Cloudflare proxy та налаштований SSL/TLS режим.
• Карта редиректів із відповідністю старих URL, нових URL і коду стану.
• SEO-чеклист: canonical-теги, sitemap, внутрішні посилання та індексація.
• Інструменти для тестування – браузер, curl або перевірка HTTP-заголовків.

Також важливо, щоб origin-сервер працював стабільно. Worker допомагає зменшити навантаження, проте некоректні налаштування DNS або SSL не компенсуються. Особливо якщо ви робитимете HTTPS-редиректи, переконайтеся, що у вашому хостингу Hostragons SSL сертифікат активний. Для допомоги рекомендуємо матеріали Як виконати встановлення безкоштовного SSL та Операції перенаправлення через cPanel.

Покрокова інструкція з налаштування безсерверних редиректів через Cloudflare Workers

1. Створення Worker

У панелі Cloudflare виберіть потрібний обліковий запис, зайдіть у розділ Workers and Pages і створіть новий Worker. Спочатку система покаже приклад коду, який можна видалити і написати власну логіку редиректів. Обирайте зрозумілі імена, наприклад seo-redirects, domain-migration-redirects або campaign-router – це спростить подальше обслуговування.

У базовому сценарії робиться прийом запиту, створюється об’єкт URL, і якщо умова співпадає, виконується перенаправлення Response.redirect із кодом 301 для постійного редиректу або 302 для тимчасового. Можна також використовувати 308, але у SEO найпоширенішим є 301.

2. Додайте просте правило 301 редиректу

Найпростіший випадок – це постійне перенаправлення старої сторінки на нову. Наприклад, якщо шлях запиту /staryj-sajt, тоді робіть редирект на /novyj-sajt з кодом 301. У Worker ви читаєте pathname з URL запиту і перевіряєте відповідність. Якщо збіг є, віддаєте редирект, інакше дозволяєте обробити запит далі.

Припустимо, ви оновили структуру категорій хостингу і перенесли /hosting-pakety на /web-hosting. Так ви повідомляєте пошуковим системам про постійний переїзд. Через кілька тижнів Google почне краще асоціювати нову адресу, але важливо уникати ланцюжків редиректів і робити посилання напряму на фінальний URL.

3. Налаштуйте маршрут Worker

Просто написати код недостатньо – потрібно вказати, на які URL він буде спрацьовувати. Наприклад, маршрут example.com/* охоплює всі шляхи домену. Якщо потрібно обмежити дію Worker певним підкаталогом, наприклад example.com/stary-blog/*, вкажіть це точніше. Занадто широкий маршрут може призвести до небажаних редиректів.

Перед запуском на продуктиві рекомендуємо тестувати на staging або тестовому піддомені, наприклад test.example.com/*. Перевірте заголовки і поведінку редиректів, і лише після підтвердження коректності застосовуйте до основного домену. Це особливо важливо під час великих SEO міграцій, щоб уникнути помилкових масових редиректів.

4. Опублікуйте і перевірте HTTP статус

Після публікації Worker недостатньо просто відкрити сторінку в браузері – кеш браузера може показати застарілий результат. Краще перевіряти статус через інструменти перегляду HTTP-заголовків: впевніться, що повертається код 301 або 302, а у заголовку Location вказано правильний фінальний URL.

• Чи веде старий URL напряму на новий?
• Чи коректний код редиректу (301 чи 302)?
• Чи немає зайвих ланцюгів HTTP→HTTPS?
• Чи узгоджені варіанти www та без www?
• Чи стандартизовано використання слешу в кінці URL?
• Чи однаковий SEO-контент для мобільних та десктопних користувачів?

Поширені сценарії редиректів

Редирект однієї сторінки

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

Масові редиректи за картою URL

Під час міграції сайту може знадобитися перенаправити десятки або сотні URL. Для цього у Worker можна створити об’єкт-мапу, де ключ – старий шлях, а значення – новий. Наприклад, /stary-blog/cloudflare-shcho-ce таке редиректитиметься на /blog/cloudflare-shcho-ce. Це зручно для невеликих і середніх списків, але для тисяч URL краще використовувати зовнішні сховища типу Cloudflare KV, R2 або API, щоб не засмічувати код.

Для масових редиректів рекомендується підготувати таблицю в Excel або Google Sheets з трьома колонками: старий URL, новий URL і код стану. Перевіряйте, щоб один старий URL не вів на кілька нових, а новий URL повертав код 200 і не був заблокований у robots.txt. Частою помилкою SEO-міграцій є масове перенаправлення старих адрес на нерелевантні сторінки нового сайту, що тимчасово зменшує помилки сканування, але знижує якість і довгостроковий рейтинг.

Редиректи за країною

Cloudflare дозволяє визначати країну користувача за IP і використовувати цю інформацію для редиректів. Наприклад, користувачів з України можна направити на /ua, а з Німеччини – на /de. Однак автоматичні редиректи за країною потребують обережності для SEO. Googlebot переважно сканує з конкретних регіонів, і некоректна настройка може ускладнити індексацію мовних версій. Тому важливо правильно використовувати hreflang, мовні перемикачі і sitemap.

Для таких сценаріїв краще використовувати тимчасові (302) редиректи, щоб не заявляти про постійний переїзд сторінки. Користувачу також потрібно дати можливість вибрати іншу мову або регіон вручну для кращого UX.

Редиректи за типом пристрою або User-Agent

Раніше мобільних користувачів часто перенаправляли на окрему мобільну версію сторінки, але сьогодні популярні адаптивні дизайни. Проте для спеціальних сценаріїв – наприклад, сторінки завантаження мобільного додатку або легкі лендинги для мобільних – редиректи за user-agent все ще застосовуються. Важливо, щоб контент для мобільних і десктопних сторінок був узгодженим, аби не створювати SEO-конфліктів.

Якщо ви налаштовуєте редиректи за пристроєм, пам’ятайте про mobile-first індексацію Google: мобільна версія сайту впливає на ранжування, тож просто оптимізувати десктопну версію недостатньо.

Редиректи за параметрами запиту для кампаній

Для маркетингових команд Worker-редиректи дуже корисні. Наприклад, якщо в URL є параметр utm_campaign=blackfriday, можна направити користувача на спеціальну сторінку акції. Це можна зробити без змін у бекенді, повністю на edge. Водночас слід зберігати UTM-параметри для аналітики: переносити їх у новий URL або налаштовувати коректний збір у системах кампаній.

Вибір між 301, 302, 307 та 308 з точки зору SEO

Код редиректу – це не просто технічна деталь, а сигнал пошуковим системам про наміри зі сторінкою. 301 означає постійний редирект і найчастіше застосовується при SEO-міграціях. 302 – тимчасовий, підходить для тестів, кампаній, гео- або пристроєвих сценаріїв. 307 зберігає HTTP-метод і зазвичай не використовується для SEO. 308 подібний до 301, але зберігає метод і підходить для API або складних сценаріїв.

Головне правило SEO: для сторінок із чітким новим відповідником – 301, для тимчасових або персоналізованих редиректів – 302. Уникайте ланцюгів редиректів, коли старий URL спочатку веде з HTTP на HTTPS, потім з non-www на www, і лише потім на нову сторінку. Ідеально, коли редирект виконується за один крок на кінцевий HTTPS URL.

Рекомендації для продуктивності та безпеки

Хоча Cloudflare Workers працюють швидко, погано написані редиректи можуть викликати затримки та помилки. Намагайтеся писати прості правила, уникайте надмірно складних регулярних виразів і не додавайте великі списки редиректів без контролю. Для великих масивів даних краще використовувати KV сховища. Також обов’язково перевіряйте, щоб URL редиректу не співпадав з поточним хостом і шляхом – це допоможе уникнути нескінченних циклів.

• Визначте відповідального за кожне правило: SEO, розробник чи маркетинг.
• Робіть бекап карти редиректів перед змінами.
• Тестуйте на staging перед запуском у продакшн.
• Переконайтеся, що редирект 301 використовується лише для постійних змін.
• Після публікації перевіряйте 10-20 випадкових URL.
• Моніторте 404 помилки та звіти Google Search Console.
• Оновлюйте внутрішні посилання з старих URL на нові.

З точки зору безпеки, будьте уважні до відкритих редиректів. Якщо використовуєте параметри запиту на кшталт next, redirect або url як ціль, це може дозволити зловмисникам використовувати ваш домен для фішингу. Застосовуйте білий список дозволених доменів для таких редиректів, наприклад тільки ваші власні або перевірені домени кампаній.

SSL-конфігурація – ще один важливий аспект. Використання Cloudflare Flexible SSL без HTTPS на origin може спричиняти цикли редиректів. Найкраще – Full або Full strict SSL з дійсним сертифікатом на сервері. Hostragons пропонує зручні рішення з SSL: придбати сертифікат SSL та Безпека корпоративного хостингу.

Особливості роботи з Hostragons

При використанні Cloudflare Workers на Hostragons потрібно враховувати три рівні: доменний DNS, налаштування хостингу і редиректи на рівні додатку. Спочатку переконайтеся, що nameserver вашого домену спрямований на Cloudflare. Далі DNS-записи повинні вказувати на сервери Hostragons, а proxy (помаранчева хмара) бути активованим.

По-друге, перевірте доменні записи в хостинг-панелі – основні домени, додаткові домени (addon) або псевдоніми (alias) мають бути коректно налаштовані. Навіть якщо редиректи відбуваються на edge, частина запитів доходить до оригінального сервера. Якщо там неправильно налаштований віртуальний хост, SSL або коренева папка, це вплине на користувацький досвід. Для допомоги радимо Посібник з перенаправлення домену та Управління хостингом cPanel.

По-третє, перевірте редиректи на рівні додатку. WordPress, Laravel, кастомні PHP-додатки або інші CMS можуть самостійно робити редиректи по HTTPS, www або мові. Якщо Worker і додаток налаштовують редиректи одночасно, можуть виникнути цикли або ланцюги. Найкраща практика – відповідальність за SEO редиректи тримати в одному шарі, наприклад всі SEO та доменні редиректи через Workers, а внутрішні логіки сесій і користувачів – в додатку.

Тестування, моніторинг і відлагодження

Після запуску редиректів моніторинг не менш важливий за налаштування. Протягом перших 24 годин перевірте ключові URL, сторінки з трафіком і беклінками, а також важливі лендинги. Відстежуйте звіти про індексацію і досвід користувачів у Google Search Console. Аналізуйте логи сервера, аналітику Cloudflare і дані Google Analytics разом, щоб швидко виявляти помилки редиректів.

Типові помилки: випадкове використання 302 замість 301, редиректи зі старих URL на головну замість коректної сторінки, різні поведінки для слешів, чутливість до регістру в URL та втрата параметрів запиту. Особливо це критично для e-commerce, SaaS і хостинг-сайтів, де неправильні редиректи впливають на продажі та конверсії.

Після публікації застосуйте простий чекліст: виберіть випадкові старі URL, перевірте їх через інструмент заголовків, переконайтесь у коді 200 на фінальній сторінці, порівняйте контент з наміром старої сторінки і підтвердіть оновлення внутрішніх посилань. Ці кроки допоможуть уникнути більшості SEO-проблем.

Приклад стратегії: міграція старих сторінок хостингу на нову структуру

Розглянемо конкретний випадок. Хостингова компанія оновлює URL-структуру: сторінки /linux-hosting, /wordpress-hosting-pakety, /ssl-bezpeka та /domain-zapyt переходять на прості /web-hosting, /wordpress-hosting, /ssl-sertyfikat і /domain-zapytannya відповідно. У Worker прописують чотири чіткі 301 правила редиректів. Паралельно оновлюють меню, футер, sitemap і canonical теги на нові URL.

Мета не лише направити користувачів на правильні сторінки, а й чітко повідомити пошуковикам про нові відповідники. Якщо стару сторінку /linux-hosting переадресувати на головну, Google може втратити контекст. А правильно направлена сторінка /web-hosting краще відповідає пошуковому наміру. Отже, карта редиректів – це не просто технічний файл, а важлива складова SEO-стратегії.

Поширені запитання

Чи безпечні для SEO редиректи через Cloudflare Workers?

Так, якщо використовувати коректні коди стану і правильні цільові URL. Для постійних переїздів застосовуйте 301, для тимчасових чи умовних – 302. Уникайте ланцюгів, циклів і редиректів на нерелевантні сторінки.

Чи потрібен origin-сервер для роботи редиректів через Worker?

Якщо редирект повністю виконується на edge, то відповідь віддається без звернення до origin. Але оскільки фінальна сторінка працює на сервері або іншій інфраструктурі, важливо, щоб хостинг, DNS та SSL були налаштовані коректно.

Чи краще використовувати Workers замість Cloudflare Page Rules?

Для простих редиректів достатньо Page Rules або Redirect Rules. Але якщо потрібна динамічна логіка за шляхом, країною, пристроєм, параметрами або мультидоменність – Workers значно гнучкіші і масштабованіші.

Чи можна змінювати 301 редирект після публікації?

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

Чи можна робити редиректи між www і без www через Workers?

Так, можна перевірити значення host і перенаправляти з non-www на www або навпаки. Головне – визначитись з одним стандартом, підготувати SSL на обидва варіанти та оновити внутрішні посилання відповідно.

Висновок

Безсерверні редиректи через Cloudflare Workers – це сучасний підхід, який забезпечує високу продуктивність і операційну гнучкість у веб-проєктах. Правильний вибір між 301 та 302, ретельне планування карти редиректів і контроль усіх технічних шарів (DNS, SSL, хостинг) допоможуть безпечно і ефективно провести SEO-міграції. Для невеликих проєктів достатньо базових правил, а для масштабних міграцій важливі тестування, моніторинг і документація.

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