Перейти до основного вмісту
CyberLab.Team

SEO · Технічне · Спринт із фіксованим обсягом

Technical SEO, який упроваджують, а не лише описують у звіті

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

Спринт technical SEO є співпрацею з фіксованим обсягом, що перетворює знахідки аудиту на впроваджені, перевірені виправлення, щоб Google міг коректно краулити, рендерити та індексувати ваш сайт. У тарифі «Швидкі правки» ваші розробники впроваджують зміни за нашими тикетами; починаючи з тарифу «Виправлення» ми також можемо впроваджувати їх самі за правами, які ви надаєте під них. Ніхто не може обіцяти, що позиції не коливатимуться під час міграції: у тарифі «Міграція і масштаб» ми знижуємо ризик повним реєстром редиректів, staging-краулінгом для перевірки паритету й моніторингом після запуску, а те, як швидко Google повторно обробить сайт, лишається на боці Google.

Фіксована ціна · Тикети для розробників · QA-краулінг після виправлень · Зареєстровані в ЄС, GDPR · EN/UK/RU/PL

у програмі Google Partner
з 2015
клієнтів з 2015
490+
відповідаємо на звернення
1 робочий день

Проблеми

Коли звіт лежить у теці, а нічого не змінюється

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

Аудит лежить у теці, а кожен реліз щось ламає

Отримали аудит-PDF на 40 сторінок, а нічого насправді не виправили
Знахідки були слушні, пріоритети зрозумілі, а потім робота застопорилася: її розтягували конкурентні пріоритети розробки, нечіткі специфікації або відсутність людини, яка б перевірила, чи виправлення справді спрацювало. Діагностика без впровадження є витратою, а не інвестицією. Ми підхоплюємо роботу з будь-якого наявного аудиту, перетворюємо знахідки на конкретні специфікації й доводимо їх до перевірки краулінгом після виправлень.
На кожному релізі команда розробки щось ламає, і ніхто не помічає, поки трафік не впаде
Залишений тег noindex зі staging, редирект, видалений під час перебудови навігації, robots.txt, що блокує ключовий розділ після оновлення CMS. Це рутинні побічні ефекти деплою, які часто спливають лише тоді, коли починає змінюватися звіт «Індексування сторінок» у Search Console. Ми знаходимо, що зламалося, забезпечуємо виправлення й підтверджуємо його краулінгом. Тариф «Міграція і масштаб» також налаштовує базову лінію повторного краулінгу й правила виявлення змін; їх виконання за розкладом після спринту оцінюється окремо.
Багатомовний сайт, де важлива лише видимість у Google, а hreflang і canonical ламаються на кожному релізі
Кожен реліз є потенційною точкою зламу: hreflang, що вказує на не ті мовні версії, canonical, що веде в несподіваний бік, noindex, що потрапляє на сторінки, які мають індексуватися. Ми добиваємося виправлення налаштувань і підтверджуємо його краулінгом. Тариф «Міграція і масштаб» додає правила виявлення змін для цих тегів; їх виконання після спринту оцінюється окремо. Актуально для бізнесу, що через Google працює з аудиторіями кількох мов ЄС.

Міграція наближається або вже пішла не так

Змінюєте платформу чи домен і боїтеся втратити позиції
Зміна структури URL, міграція на HTTPS і перехід на іншу CMS належать до найризикованіших моментів у житті сайту. Карта редиректів із прогалинами, staging-файл robots.txt, залишений на проді, чи canonical, що вказує на старий домен, можуть позбавити новий сайт позицій, перш ніж хтось це помітить. Ми будуємо запобіжники до перемикання й стежимо за сигналами протягом чотирьох тижнів після нього. Повний сценарій міграції входить до тарифу «Міграція і масштаб».
Після зміни платформи чи домену трафік просів, а підрядник віддав звіт і зник
Ми підхоплюємо міграцію на будь-якому етапі: перебудовуємо повну карту редиректів, порівнюємо staging-краулінг із продом, відстежуємо сигнали Search Console у перші чотири тижні після запуску й закриваємо знайдені прогалини настільки рано, наскільки дозволяють сигнали. Як швидко Google обробить сайт далі, залежить від Google, і дати повернення позицій ми не обіцяємо. Ця робота входить до тарифу «Міграція і масштаб». Актуально для бізнесів, які за останні роки змінили CMS чи домен.

Google не обходить, не рендерить або не індексує важливі сторінки

Google не обходить нові сторінки або сторінки постійно випадають з індексу
На великих чи фасетних сайтах Googlebot може витрачати значну частину обходу на варіації фільтрів і пагіновані URL замість категорійних і товарних сторінок, які мають значення. Аналіз лог-файлів показує точно, куди йде обхід, а робота з crawl budget усуває зайві витрати, щоб краулер міг дістатися потрібних вам сторінок. На невеликому сайті причина зазвичай криється в іншому, і під час експрес-розбору ми розрізняємо ці випадки. Аналіз лог-файлів входить до тарифу «Виправлення».
Сайт насичений JavaScript, і немає певності, що Google реально бачить контент
Односторінкові застосунки й headless-фронтенди можуть добре виглядати у браузері, тоді як HTML, який Google отримує спочатку, майже порожній, і контент індексується лише після того, як Google відрендерить сторінку. Текст, що не потрапляє на відрендерену сторінку, скрипти, заблоковані robots.txt, і відкладене завантаження, яке чекає прокручування чи кліку, додають проблем. Ми діагностуємо розрив і забезпечуємо виправлення рендерингу, а не просто документуємо його. Робота з рендерингом входить до тарифу «Виправлення».
Магазин генерує тисячі сміттєвих URL фільтрів, і Google індексує варіації замість категорій
Фасетна навігація на платформах на кшталт Shoper, IdoSell чи PrestaShop може породжувати тисячі доступних для обходу комбінацій фільтрів, що марнують краулінг і сповільнюють виявлення категорійних сторінок, які мали б ранжуватися. Це управління індексом, а не черговий аудит: ми проєктуємо й упроваджуємо політику обробки параметрів, правила пагінації й правила noindex, щоб саме сторінки, які приносять продажі, ви пропонували Google для індексації. Контроль індексації входить до тарифу «Виправлення».

Як розв'язуємо

Що ви отримуєте наприкінці спринту

Кожен спринт закривається трьома артефактами. Щоб зрозуміти, що було зроблено, не потрібна жодна додаткова співпраця.

  1. Пріоритезований перелік виправлень у форматі тикетів

    Кожен тикет називає проблему, точну специфікацію й критерії приймання. Ваші розробники можуть виконувати їх без додаткових запитань.

  2. QA-краулінг після деплою, до та після

    Після впровадження кожної партії виправлень ми повторно краулимо й порівнюємо. Кожне виправлення перевірене, а не припущене.

  3. Знімок Search Console із базовою лінією до виправлень

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

Приклад тикета

Пріоритет: високий

Звести дублікати URL фільтрів під один canonical

Проблема: /category/shoes/ і /category/shoes/?sort=price обидва повертають 200 і мають self-canonical, дроблячи сигнали індексації.

Специфікація: вказати rel=canonical на кожному варіанті ?sort= на чистий URL категорії та лишити параметр доступним для краулінгу, бо блокування в robots.txt не дасть Google прочитати цей canonical. Чи закривати параметр далі й яким механізмом, вирішується за конкретним сайтом і даними логів, а не спільним правилом на всі магазини.

Критерії приймання: QA-краулінг показує нуль self-canonical варіацій ?sort=; URL категорій не змінюються й повертають 200.

Ілюстративний приклад, а не реальний клієнтський результат.

Що ми виправляємо

Частину роботи, яка починається зі старшого тарифу, позначено на її картці.

Упровадження виправлень і специфікації, готові для розробників

Беремо знахідки з вашого наявного аудиту (нашого чи стороннього) і перетворюємо їх на пріоритезовані тикети, готові до Jira, які ваша команда розробників може виконати без двозначностей: карти редиректів, набори правил canonical, директиви robots.txt і політики meta-тегів. Після того як ваші розробники впроваджують кожну партію, ми робимо QA-краулінг, щоб підтвердити: виправлення лягло правильно й нічого суміжного при цьому не зламалося.

Кожен спринт. Самі впроваджуємо зміни, починаючи з тарифу «Виправлення»

Міграції сайтів і SEO при зміні платформи

Зміна домену, міграція на HTTPS, перехід на іншу CMS і перебудова структури URL є моментами підвищеного ризику: пропущена карта редиректів чи staging-файл robots.txt, залишений на проді, можуть завадити Google обходити новий сайт, доки хтось це не виправить. Ми будуємо повний реєстр редиректів до перемикання, робимо staging-краулінг для порівняння паритету з поточним сайтом і стежимо за Search Console та логами краулінгу в перші чотири тижні після запуску.

«Міграція і масштаб»

Аналіз лог-файлів та інженерія crawl budget

Серверні логи показують, що Googlebot насправді запитує, а не те, що ви припускаєте про обхід. Ми обробляємо ваші сирі лог-файли, щоб знайти марнування краулінгу на малоцінних URL, звернення до перенаправлених чи видалених сторінок і сторінки, важливі для позицій, які Googlebot рідко завантажує. На великих чи фасетних сайтах ми готуємо конкретні рекомендації щодо правил robots.txt, внутрішніх посилань і карт сайту.

«Виправлення» та вище

JavaScript-рендеринг і виправлення рендерингу

Ми точно діагностуємо, де ваша конфігурація CSR, SSR чи гідратації залишає контент поза відрендереною сторінкою, яку індексує Google, або невидимим для краулерів, що не виконують JavaScript, а потім забезпечуємо виправлення, а не просто документуємо його. Робота охоплює коригування налаштувань SSR чи prerender, виправлення відкладеного завантаження, щоб контент завантажувався, коли стає видимим, і перевірку структурованих даних у відрендереному HTML. Ми віддаємо перевагу структурованим даним у серверному HTML, бо так надійніше, особливо для ціни й наявності товару.

«Виправлення» та вище

Контроль індексації в масштабі

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

«Виправлення» та вище

Моніторинг технічного здоровʼя та захист від регресій

Базова лінія повторного краулінгу, перевірки Search Console і правила виявлення змін дають змогу помітити на наступній перевірці наслідки рутинного релізу, що повернув тег noindex, прибрав редирект або зламав налаштування canonical, а не через тижні в даних про трафік. Те, чи встиг Google до того моменту повторно обійти сторінку, не контролює ніхто, тому перевірка й іде за розкладом, а не після падіння.

Налаштування: «Міграція і масштаб». Виконання після спринту: оцінюється окремо

Як виглядає беклог, на прикладі нашого реєстру

Кожна проблема отримує рівень серйозності, перевірку, яка визначає, коли її можна вважати виправленою, і відповідального: хто впроваджує, погоджується до початку спринту.

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

Приклад, а не дані клієнта
  1. Директива staging, що блокує сканування, живе на публічному хості

    Критично

    Критерій приймання: Живий файл robots дозволяє публічні розділи, а блокуюче правило лишається тільки на staging

    Власник: Ми, хостинг підтверджує

  2. Текст на шаблоні послуги виникає лише після гідратації

    Критично

    Критерій приймання: Перший абзац присутній у сирій HTML відповіді на кожній сторінці послуги

    Власник: Розробник клієнта, ми пишемо специфікацію

  3. Старі URL товарів доходять до призначення через два переходи редиректу

    Високий

    Критерій приймання: Кожен старий URL доходить до призначення одним постійним редиректом

    Власник: Ми

  4. Параметри фільтрів створюють доступні для сканера URL, яких ніхто не шукає

    Високий

    Критерій приймання: Для сканування і індексації лишаються тільки комбінації з узгодженої політики параметрів

    Власник: Ми з розробником клієнта

Кому цей спринт підходить і кому не підходить

Гарний вибір, якщо у вас є

  • Великий чи фасетний сайт, де crawl budget та індексація потребують свідомого контролю
  • Фронтенд, насичений JavaScript, і сумніви щодо того, що насправді бачить Googlebot
  • Міграція, зміна платформи чи домену, запланована в календарі, або така, що вже пішла не так
  • Аудит (наш чи сторонній), який лежить невпровадженим

Не та сторінка, якщо вам потрібно

  • Контент-стратегія чи лінкбілдинг. Ні того, ні того на цій сторінці ми не продаємо.
  • Глибока діагностика Core Web Vitals. Це належить до SEO аудит сайту, який має інструментарій, щоб ізолювати причини LCP, INP і CLS.
  • Роботу на рівні плагінів WordPress, як-от конфігурація Yoast чи Rank Math. Це належить до WordPress SEO.
  • Перебудову самого сайту. Для цього є розробка сайтів.

Міграції

Як ми проводимо міграцію

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

  1. До перемикання

    Ми будуємо повний реєстр редиректів, краулимо staging-середовище, щоб перевірити паритет URL і логіку canonical, і перевіряємо, що staging-файл robots.txt випадково не потрапить на прод.

  2. День запуску

    Ми стежимо за доступом краулінгу, поведінкою редиректів і першими сигналами Search Console у момент, коли новий сайт виходить у прод, тож проблеми з доступом краулінгу й редиректами спливають у день запуску, а не через тижні.

  3. Тижні з 1-го по 4-й після

    Поки Google повторно обробляє сайт, ми відстежуємо індексування сторінок, активність краулінгу й сигнали позицій. Прогалини закриваємо, доки вони не переросли в довшу втрату.

Відновлення міграції, яка вже пішла не так

Ми можемо підхопити міграцію посеред проєкту чи після запуску: перебудувати реєстр редиректів, зіставити staging-краулінг із продом і розбирати падіння у звіті «Індексування сторінок» у Search Console. Одне застереження ми називаємо прямо: швидкість відновлення залежить від циклу повторного обходу Google, тож ми ніколи не обіцяємо строк повернення позицій.

Процес

Як проходить спринт

  1. Експрес-розбір

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

  2. Обсяг і права, письмово

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

  3. Тикети й виправлення

    Кожен тикет містить специфікацію й критерії приймання. У тарифі «Швидкі правки» їх впроваджують ваші розробники; починаючи з тарифу «Виправлення» ми можемо впроваджувати самі за наданими вами правами.

  4. QA-краулінг і передача результатів

    Після кожної партії ми повторно краулимо й перевіряємо критерії приймання. Для краулінгу й аналізу використовуємо власні розробки, Screaming Frog SEO Spider, Google Search Console, Ahrefs і PageSpeed Insights. Спринт завершується звітом QA-краулінгу, знімком Search Console до та після й поверненням усіх тимчасових прав.

Подивімося на ваш беклог

Починаємо з безкоштовного експрес-розбору з кроку 1. Після нього рішення за вами.

Отримати експрес-розбір

Що потрібно від вас для початку

Вам не потрібно передавати пароль. Решту узгодимо під час безкоштовного експрес-розбору.

  • Ваш аудит або чітко окреслена проблема. Наш чи сторонній. Без аудиту ми теж можемо почати, коли задача зрозуміла, наприклад міграція чи відомий збій рендерингу.
  • Доступ на читання до Search Console й Analytics. Через запрошення, ніколи не пароль. Коли виправлення впроваджує ваша команда, цього й краулінгу публічного сайту вистачає для більшої частини роботи; експорт логів чи доступ до staging додається там, де цього потребує спринт.
  • Права на запис під погоджену правку, якщо впроваджуємо ми. Саме ті, яких вимагає тикет, наприклад розгортання одного файлу robots.txt або роль редактора на одному шаблоні, надані на час спринту й відкликані з його закриттям.
  • Експорт сирих логів доступу для аналізу лог-файлів. Починаючи з тарифу «Виправлення». Достатньо експорту з панелі вашого хостингу або CDN за обраний вами діапазон дат. Без SSH чи адмінського доступу.
  • Доступ до staging і вікно запуску для міграції. У тарифі «Міграція і масштаб». Хто впроваджує кожну зміну, ми чи ваша команда, фіксується до старту спринту.

Ціна

Ціни на спринти Technical SEO

Кожна співпраця починається з безкоштовного експрес-розбору. Кожен тариф визначає, хто змінює код: «Швидкі правки» дають специфікацію та перевірку, а зміни впроваджує ваша команда; у двох інших ми можемо впроваджувати самі за правами, наданими під погоджену правку. Режим роботи й потрібні йому права узгоджуються до початку робіт, а не після.

Швидкі правки
€199 за спринт
Сфокусоване виправлення на визначеному наборі знахідок у режимі специфікації: тикети, критерії приймання та перевірка після деплою наші, зміни впроваджує ваша команда. Підходить меншим сайтам або одній пріоритетній проблемній зоні.
  • Пріоритезований перелік виправлень за знахідками вашого аудиту (нашого чи стороннього)
  • Тикети, готові для розробників: карти редиректів, правила canonical, директиви robots
  • QA-краулінг після виправлень, щоб підтвердити, що вони лягли правильно
  • Перевірка сигналів Search Console і краулінгу після впровадження
  • Безкоштовний експрес-розбір
Замовити Швидкі правки
Міграція і масштаб
€750 за спринт
Міграції сайтів, зміна платформи чи масштабне виправлення індексації на сайтах зі складною інфраструктурою. Хто впроваджує кожну зміну, ми за наданими правами чи ваша команда, фіксується до старту спринту.
  • Усе з тарифу «Виправлення»
  • Повний сценарій міграції: реєстр редиректів, staging-краулінг паритету, чек-лист дня запуску
  • Моніторинг протягом чотирьох тижнів після запуску (Search Console, логи краулінгу, сигнали позицій)
  • Налаштування захисту від регресій: базова лінія повторного краулінгу й правила виявлення змін

Моніторинг після спринту оцінюємо окремо, якщо він потрібен.

Замовити Міграція і масштаб

Що додає кожен спринт

Тариф «Швидкі правки» коштує €199 і охоплює визначений набір знахідок. Тариф «Виправлення» (€399) додає роботу з JavaScript-рендерингом, аналіз лог-файлів і контроль індексації. Тариф «Міграція і масштаб» (€750) охоплює повний сценарій міграції плюс чотири тижні моніторингу після запуску й налаштування захисту від регресій. Постійний моніторинг ми оцінюємо на запит уже після першого спринту, бо правильна періодичність залежить від розміру вашого сайту й графіка релізів.

Не хочете заповнювати форму? Напишіть нам у Telegram (t.me/cyberlabteam) або WhatsApp (+48 668 155 303).

Три способи працювати з нами

Режим 1

Впроваджуємо самі

Цьому режиму потрібні права на запис: саме ті, яких вимагає погоджена правка, наприклад розгортання одного файлу robots.txt або роль редактора на шаблоні, який виправляємо, надані на час спринту й відкликані з його закриттям. Доступу лише на читання для впровадження не вистачає, і ми називаємо потрібні права за кожним тикетом ще до того, як ви щось надасте. Ми впроваджуємо виправлення, робимо QA-краулінг і повертаємо все задокументованим. Доступно починаючи з тарифу «Виправлення».

Режим 2

Ваші розробники впроваджують, ми пишемо специфікації й робимо QA

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

Режим 3

Моніторинг після спринту, якщо він того вартий

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

Чому ми

Наш досвід

CyberLab.Team OÜ є Google Partner з 2015 року.

Google Partner
  • з 2010 працюємо з пошуком і рекламою Google
  • 490+ клієнтів за час роботи
  • 15 країн, де працюють наші клієнти
  • з 2014 у команді є Google Top Contributors і Product Experts

Наша команда має 9 сертифікацій Google

  • Пошукова реклама Google Ads
  • Відеореклама Google Ads
  • Медійна реклама Google Ads
  • Товарна реклама (Shopping)
  • Реклама застосунків Google Ads
  • Вимірювання ефективності Google Ads
  • Оптимізація конверсій
  • Google Analytics
  • Display & Video 360

Без привʼязки, працюємо з вашою наявною командою

Ретейнер-контракт не потрібен, і мінімуму понад замовлений спринт немає. Експрес-розбір відбувається до будь-якої оплати: до двадцяти хвилин розмови, до трьох перших знахідок або кроків, без письмового звіту.

  • Обсяг і ціна фіксуються до початку. Тикети в обсязі робіт і ціна погоджуються письмово до початку роботи, тож жодних несподіванок щодо обсягу чи ціни.
  • Доступ із мінімальними правами або без доступу. Починаючи з тарифу «Виправлення», там, де ви надаєте обмежений доступ, ми впроваджуємо самі; там, де ви віддаєте перевагу власним розробникам, ми передаємо специфікації, достатньо точні, щоб виконати їх без нашої участі. Ваші CMS, Search Console й хостинг залишаються повністю під вашим контролем.
  • Реєстрація в ЄС, GDPR. За кожним договором стоїть юридична особа CyberLab.Team OÜ, естонський реєстраційний код 14647320. Ми працюємо за GDPR і підписуємо DPA на запит.
  • Прозорі ціни за спринт. Ціни всіх трьох спринтів наведено разом із пакетами, довгострокового контракту немає.

Моделі співпраці

Чому спринт із фіксованим обсягом

У спринту є визначений обсяг, опублікована ціна й кінцева точка. Ви платите за визначений, перевірений результат, а не за відпрацьовані години. Моніторинг після спринту оцінюється за потреби й не привʼязує вас наперед.

Фіксований спринт CyberLabТиповий ретейнер агенціїФрилансер погодинно
Опублікована цінаФіксований спринт CyberLab€199 / €399 / €750, на цій сторінціТиповий ретейнер агенціїРозцінка після дзвінка з продажуФрилансер погодинноПогодинна ставка, підсумок відкритий
Визначений обсяг і кінцева точкаФіксований спринт CyberLabФіксований обсяг, закривається, коли виправлення перевіреніТиповий ретейнер агенціїБезстрокове щомісячне зобовʼязанняФрилансер погодинноОбсяг пливе разом із годинами
QA після виправленьФіксований спринт CyberLabQA-краулінг після кожної партії виправленьТиповий ретейнер агенціїЗалежить від агенціїФрилансер погодинноРідко входить
Реєстрація в ЄС, GDPR, DPAФіксований спринт CyberLabЗареєстровані в ЄС, DPA на запитТиповий ретейнер агенціїЗалежитьФрилансер погодинноЗалежить
ПривʼязкаФіксований спринт CyberLabНемає, по одному спринту за разТиповий ретейнер агенціїЗазвичай контракт на кілька місяцівФрилансер погодинноНемає, але безперервність роботи залежить від однієї людини

Узагальнені архетипи співпраці для орієнтування, а не конкретні компанії.

Приклад роботи

Як це виглядає на практиці?

Одна робота: інтернет-магазин прийшов з аудитом піврічної давності від іншого підрядника. Знахідки були слушні, але нічого не було впроваджено. Ми почали з дзвінка про обсяг, свіжим краулінгом підтвердили, які знахідки все ще актуальні, і перетворили головні пункти на готові для розробників тикети: чистка редиректів, правила canonical для URL фільтрів і виправлення robots.txt, що блокувало розділ товарів. Власні розробники магазину впровадили зміни за два релізні цикли. Після кожного релізу ми робили QA-краулінг, щоб підтвердити: виправлення лягли й нічого суміжного не зламалося. У підсумковому документі ми порівняли стан Search Console до та після: заблоковані розділи знову доступні для обходу, а дублікати варіацій зведені.

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

Питання

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

Обсяг, ціна й терміни

Скільки коштує спринт і від чого залежить рівень?
Три тарифи спринтів коштують €199, €399 і €750. Правильний тариф залежить від обсягу виправлень: сфокусований тариф «Швидкі правки» для визначеного набору проблем, «Виправлення» для роботи з кількома проблемами, включно з JavaScript-рендерингом та інженерією crawl budget, чи «Міграція і масштаб» для проєктів зі зміною платформи або масштабної роботи з індексацією на великих сайтах. Точний тариф ми підтверджуємо після безкоштовного експрес-розбору; на ваше перше повідомлення відповідаємо протягом 1 робочого дня.
Скільки триває спринт?
Залежить від тарифу й від того, як часто деплоїть ваша команда розробки. Тариф «Швидкі правки» із чітким обсягом рухається швидше, ніж міграція, яка потребує перегляду staging і вікна запуску. Очікувану тривалість ми підтверджуємо під час безкоштовного експрес-розбору, до того як ви берете на себе зобовʼязання, тож ви отримуєте строк саме під ваш обсяг, а не загальну оцінку.
Що саме ми отримуємо, коли спринт завершується?
Три речі. Перша: самі виправлення, які ми впроваджуємо під обмеженим доступом, починаючи з тарифу «Виправлення», або готові тикети, за якими їх впроваджують ваші розробники. Друга: звіт QA-краулінгу після виправлень, який підтверджує, що кожна зміна лягла правильно й нічого суміжного не зламалося. Третя: знімок стану Search Console до та після, тож і базова лінія до виправлень, і стан після них задокументовані в даних. Спринт закривається перевіреними змінами, а не черговим звітом про те, що мало б статися.
Це разовий проєкт чи постійна співпраця?
Спринти є разовими співпрацями з фіксованим обсягом. Після завершення спринту постійний моніторинг і захист від регресій можна оцінити як окрему співпрацю залежно від розміру вашого сайту й періодичності релізів. Ми не публікуємо тут ретейнер-ціну, бо правильний обсяг суттєво різниться. Під час безкоштовного експрес-розбору ми зʼясовуємо, чи має сенс постійний моніторинг для вашої ситуації і що саме він охоплюватиме.
Чи можете ви гарантувати позиції або відновлення трафіку після виправлень?
Ні, і ми прямо скажемо чому. Technical SEO усуває барʼєри, які заважають Google коректно краулити, рендерити та індексувати ваш контент. Чи перетвориться це на вищі позиції й більший трафік, залежить від якості контенту, конкурентного середовища й власної оцінки Google, а нічого з цього ми не контролюємо. Ми можемо підтвердити, що технічні блокери усунуто й перевірено, а стан до та після ми вимірюємо, тож вплив видно в даних, а не в обіцянці.

Чи підходить ця послуга?

Чим це відрізняється від вашого SEO Site Audit?
SEO Site Audit є діагностикою: ми краулимо й аналізуємо ваш сайт, виявляємо кожну значущу технічну проблему й передаємо пріоритезований звіт зі специфікаціями на кожне виправлення. Ця послуга є впровадженням: ми беремо ці знахідки (з нашого аудиту чи будь-якого стороннього) і добиваємося, щоб виправлення впровадили ваші розробники за нашими тикетами або ми, починаючи з тарифу «Виправлення», а потім перевіряємо, що вони спрацювали. Ви можете спершу замовити аудит, а потім залучити нас на виконання. Ви також можете почати тут, якщо у вас уже є свіжий аудит з іншого джерела або якщо проблема достатньо конкретна, щоб визначити обсяг швидше, ніж проводити повну діагностику.
Чи потрібен аудит, перш ніж ви почнете виправляти?
Ні. Якщо у вас уже є свіжий аудит, наш чи будь-чий, ми можемо працювати безпосередньо з цими знахідками. Якщо аудиту немає, але є конкретна, чітко окреслена проблема (міграція, яку треба провести безпечно, відомий вам збій JavaScript-рендерингу, проблема crawl budget на великому фасетному сайті), ми визначаємо обсяг спринту навколо неї. Під час безкоштовного експрес-розбору ми разом вирішуємо, чи потрібна попередня діагностика, чи обсяг уже достатньо ясний, щоб починати.
Фасетна навігація й URL фільтрів у магазині: це правильна послуга?
Частково. Інженерія crawl budget і контроль індексації для параметричних URL (рішення, які комбінації фільтрів обходяться, які отримують noindex і як працює ієрархія canonical) належать до профільної роботи тут, починаючи з тарифу «Виправлення». Стратегія органічного ранжування для категорійних і товарних сторінок, включно з написанням Product schema, глибиною контенту категорій та архітектурою сайту під каталог, належить до нашої послуги E-commerce SEO. Магазину може бути потрібне і те, й інше: спершу виправлення інфраструктури тут, а потім робота з контентом і schema там.
Чи охоплюєте ви Core Web Vitals і швидкість сторінок?
Ми виправляємо проблеми рендерингу й доставки, що впливають на те, наскільки швидко контент доходить і до користувачів, і до краулерів: конфігурація SSR, відкладене завантаження, обробка ресурсів, що блокують рендеринг, і TTFB. Глибока діагностика Core Web Vitals (визначення, який саме елемент LCP повільний, кількісна оцінка INP за даними реальних користувачів, ізоляція джерел CLS на шаблонах сторінок) належить до SEO Site Audit, який має відповідні обсяг робіт та інструментарій для такого рівня роботи з продуктивністю. Якщо ваша головна турбота Core Web Vitals, краще почати саме з нього.
А як щодо структурованих даних і schema-розмітки?
Ми переконуємося, що ваша наявна schema валідна, присутня в HTML, який рендерить Google, бажано вже в серверному HTML, і використовує актуальний словник schema.org. Ми також додаємо чи виправляємо розмітку BreadcrumbList, яка міститься в шаблоні сайту, а не в контенті. Карта сайту й canonical структурованими даними не є: перша є XML-файлом, а другий елементом link у HTML, і ми працюємо з ними там, де вони живуть, а не називаємо їх розміткою. Написання нової schema під типи контенту (Article та подібні) охоплюється нашою послугою AI SEO, яка спеціалізується саме на цьому шарі.
А як щодо WordPress чи конкретної CMS?
Ця послуга не залежить від CMS: ми працюємо з будь-якою платформою й упроваджуємо виправлення на рівні серверної конфігурації та вихідного HTML, незалежно від того, що генерує сторінки. Специфічні для CMS питання (конфігурація Yoast і Rank Math, політики архівів таксономій WordPress, конфлікти стека плагінів, індексація архівів товарів WooCommerce) належать до нашої послуги WordPress SEO, побудованої саме навколо платформного шару WordPress. Якщо ви не певні, що з цього ваш випадок, це прояснить експрес-розбір.
Чи можуть AI-краулери завантажувати й розбирати мій сайт?
Проблеми інфраструктури, що стримують Googlebot, зазвичай стримують і AI-краулери: рендеринг лише через JavaScript, який не можуть прочитати краулери, що не виконують скриптів, надто широкі правила Disallow у robots.txt і повільні відповіді, через які краулери завантажують меншу частину сайту. Ми виправляємо це на рівні інфраструктури й розбираємо ваш robots.txt окремо за кожним агентом, бо ці боти роблять різне: Googlebot краулить для Google Search і повʼязаних продуктів, Google-Extended слугує токеном robots.txt, який визначає, чи можна використовувати контент, який Google обійшов, для навчання та обґрунтування відповідей моделей Gemini, без жодного впливу на пошук, а GPTBot, ClaudeBot і PerplexityBot належать іншим компаніям. Кого з них пускати, ви вирішуєте як власник бізнесу, тож відкривати всіх поспіль ми не радимо; ми натомість перевіряємо, чи не заблоковано через недогляд те, що ви хотіли дозволити. Чи перетвориться це на цитування у відповідях, згенерованих AI, визначають контент і сутності, а не інфраструктура. Ця робота належить до наших послуг AI SEO та AI Visibility.

Робота з вашою командою й сайтом

Чи можете ви працювати з нашими розробниками, готувати тикети для Jira й робити QA після їхнього деплою?
Так, це для нас звичайний режим роботи. Ми готуємо структуровані специфікації (карти редиректів, логіку canonical, зміни директив robots, шаблони meta-тегів), оформлені так, щоб розробник, незнайомий із початковим аудитом, упровадив їх без додаткових запитань. Після впровадження кожної партії виправлень ми робимо QA-краулінг після деплою, щоб підтвердити: зміни лягли правильно й нічого суміжного не зламалося. Ми також можемо переглядати pull request чи staging-середовища, перш ніж вони підуть у прод.
Ви справді вноситимете зміни на нашому сайті чи просто створите ще документацію?
Ми впроваджуємо напряму там, де ви надаєте права на запис під конкретну правку: staging-середовище, robots.txt через ваш хостинг або роль у системі керування сайтом, обмежену сторінками конфігурації з тикета. У тарифі «Швидкі правки» усе навпаки: специфікація та перевірка наші, а зміни впроваджує ваша команда, і ціну тарифу закладено саме під це. Там, де ви віддаєте перевагу власній команді на роботу з кодом, ми готуємо специфікації, достатньо точні, щоб виконати їх без нашої участі. У будь-якому разі спринт завершується тим, що виправлення впроваджено й перевірено після релізу, а не документом з описом того, що хтось має зробити. Ваші акаунти й CMS лишаються під вашим контролем увесь час.
Ви працюєте разом із нашою наявною SEO-агенцією або під white-label для агенцій?
Так, і те, й інше. Якщо агенція вже веде ваш контент і посилання, ми долучаємося як незалежна команда технічного впровадження й координуємося через їхній чи ваш беклог. Агенції також залучають нас під власним брендом для міграцій і технічного виправлення. У будь-якому разі привʼязки немає, акаунти ми не перебираємо на себе, а доступ обмежений, його можна відкликати, і він залишається у вашій власності.
Де обробляються дані й як ви безпечно отримуєте доступ до нашого сайту?
CyberLab.Team OÜ зареєстрована в Таллінні, Естонія (ЄС), і працює за GDPR. Угоду про обробку даних (DPA) ми надаємо на запит, перш ніж починати будь-яку роботу. Коли зміни впроваджує ваша команда, нам потрібні доступ на читання до Search Console й Analytics та краулінг публічного сайту, а для деяких спринтів ще й експорт логів чи доступ до staging. Коли зміни впроваджуємо ми, потрібні права на запис під конкретну правку з тикета, наприклад до одного шаблона в системі керування сайтом або на розгортання robots.txt, але ніколи права на білінг чи керування користувачами. Який режим діє та які права йому потрібні, фіксується до початку робіт. Ми ніколи не просимо адмінських облікових даних, які нам не потрібні, ніколи не зберігаємо облікові дані доступу поза межами співпраці, а ваші акаунти залишаються повністю у вашій власності під час роботи й після неї.
Чи потрібен вам доступ до сервера для аналізу лог-файлів?
Ні. Нам не потрібен адмінський чи SSH-доступ. Достатньо експорту сирих логів доступу з панелі вашого хостингу або лог-файлів з CDN (Cloudflare, Fastly тощо). Ви обираєте діапазон дат і передаєте файли. Це тримає співпрацю в межах моделі найменших привілеїв, описаної на цій сторінці, а DPA надається на запит.

Міграції, краулінг і рендеринг

Як ви проводите міграцію чи зміну платформи?
Ми розбиваємо це на три етапи: до, під час і після. До перемикання ми будуємо повний реєстр редиректів, краулимо staging-середовище, щоб перевірити паритет URL і логіку canonical, і перевіряємо, що robots.txt зі staging випадково не потрапить у прод. У день запуску ми стежимо за доступом краулінгу й початковими сигналами Search Console. Протягом чотирьох тижнів після запуску ми відстежуємо індексування сторінок, активність краулінгу й сигнали позицій і виправляємо будь-які прогалини, що зʼявляються, до того, як вони накопичаться в довшу втрату позицій. Мета в тому, щоб уявлення Google про ваш сайт змінилося без збоїв, а не почалося з нуля. Повний сценарій міграції входить до тарифу «Міграція і масштаб».
Чи можете ви перебрати міграцію, яку почав інший підрядник, або виправити ту, що вже зірвалася?
Так, на будь-якому етапі. Посеред міграції ми перебудовуємо реєстр редиректів і зіставляємо staging-краулінг із продом до перемикання. Після запуску розбираємо падіння у звіті «Індексування сторінок» й закриваємо прогалини редиректів у порядку пріоритету. Одне чесне застереження: наскільки швидко відновляться позиції, залежить від циклу повторного обходу Google, який ніхто поза Google не контролює, тож ми ніколи не обіцяємо строк відновлення. Ця робота входить до тарифу «Міграція і масштаб».
Що таке crawl budget і чи є насправді проблема в мого сайту?
Crawl budget складається з URL, які Google може обійти з огляду на можливості вашого сервера й хоче обійти з огляду на важливість і свіжість ваших сторінок. Для більшості невеликих сайтів він не створює суттєвого обмеження: власну довідку про нього Google написав для великих сайтів, сторінки яких часто змінюються. Це стає реальною проблемою на великих сайтах, в інтернет-магазинах із фільтрованою навігацією чи на сайтах із розростанням URL через параметри, де Googlebot може витрачати значну частину обходу на малоцінні варіації замість сторінок, які мали б ранжуватися. Ми використовуємо серверні лог-файли, щоб показати вам, куди реально йде обхід, і це часто не те місце, де ви його уявляєте. Аналіз лог-файлів входить до тарифу «Виправлення» та вище.
Сайт насичений JavaScript: чи бачить Google мій контент і що ви виправляєте?
Googlebot може виконувати JavaScript, але рендеринг відбувається окремим кроком після краулінгу: сторінка чекає в черзі на рендеринг, зазвичай секунди, іноді довше. Деякі патерни контенту все одно спричиняють проблеми: основний текст, який залежить від скриптів, заблокованих robots.txt, або тих, що не виконуються, відкладене завантаження, яке чекає прокручування чи кліку, яких Googlebot не робить, і розриви гідратації, де серверний і клієнтський контент різняться; останнє ми перевіряємо самостійно, і це не задокументоване правило Google. Ми точно діагностуємо, що саме з цього стосується вашого сайту, поєднуючи інспекцію сирого коду, порівняння рендерингу й дані логів, потім забезпечуємо виправлення (конфігурація SSR, prerendering чи зміни відкладеного завантаження) і перевіряємо результат у сирому HTML до й після. Робота з рендерингом входить до тарифу «Виправлення» та вище.

Ще не знаєте, що саме зламано?

Почніть із SEO аудит сайту: глибока технічна діагностика, аналіз Core Web Vitals і пріоритезована дорожня карта. Потім передайте цю дорожню карту нам на впровадження. Проблеми платформ WooCommerce чи WordPress розглядає WordPress SEO, а органічну видимість категорійних і товарних сторінок магазину веде E-commerce SEO. Працюєте із сигналами Search Console? Google Search Console Expert охоплює налаштування й діагностику.

Усі SEO-послуги зібрано в SEO-хабі.

Заявка

Готові передати нам список виправлень?

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

Без зобов'язань. Відповідь протягом одного робочого дня.

Напишіть у месенджер або заповніть форму нижче, як вам зручніше.

* Обов'язкове поле

Потрібна послуга

Technical SEO

Надсилаючи форму, ви підтверджуєте, що ознайомилися з Політикою конфіденційності.