Глава 16
Технічне SEO як система, а не контрольний список
Як перейти від аудиту на 200 пунктів до причинно-наслідкової моделі: простір URL → сканування → відтворення сторінок → канонізація → індексування → показ у результатах пошуку → моніторинг. Як визначати пріоритетність технічних дефектів за впливом, масштабом і вартістю виправлення.
Контрольний список корисний як памʼятка, але небезпечний як модель. Він ставить поруч «відсутня іконка сайту», «канонічна URL повертає 404» і «правила для роботів блокують товарні сторінки», хоча їхній вплив на бізнес відрізняється на порядки. Технічне SEO стає дієвим, коли кожен дефект повʼязаний з етапом обробки, набором уражених URL і спостережуваним результатом.
16.1Початкові дефекти породжують шум на наступних етапах
Якщо шаблон генерує мільйон URL із параметрами, на наступних етапах ви побачите надмірне сканування, конфлікти канонічних URL, виключення з індексу, шум у журналах, захаращені звіти про охоплення в GSC і розпорошення сигналів ранжування. Усувати кожен симптом окремо — марно. Я шукаю найранішу точку, у якій система почала створювати надлишковий простір URL.
16.2Серйозність = вплив × масштаб × впевненість, а не позначка «Критично» від сканера
Автоматизований інструмент аудиту не знає цінності URL для бізнесу. Відповідь 404 за старим тестовим шляхом може взагалі не бути проблемою; 302 замість 301 під час переходу на інший домен — серйозною. Я оцінюю, скільки цінних URL уражено, який механізм пошуку порушено, наскільки ми впевнені в причинно-наслідковому звʼязку, скільки коштує виправлення та чи є ризики під час його впровадження.
16.3Тестуйте шаблон, а не URL
На сайті з 2M сторінок майже кожна технічна проблема є проблемою шаблону. Вибірка по 20-50 URL для кожного шаблону дає більше, ніж випадкове сканування 500k URL без класифікації. Я завжди додаю поле page_type до наборів даних сканування, GSC і журналів. Тоді «невідповідність канонічних URL — 7%» перетворюється на «невідповідність канонічних URL у шаблоні варіантів товару — 63%».
16.4Контроль якості перед випуском важливіший за щорічний технічний аудит
Найкраща система технічного SEO виявляє регресії в день випуску. Для критичних шаблонів я автоматизую базові перевірки працездатності: відповіді HTTP, правила для роботів, канонічні URL, hreflang, структуровані дані, селектор основного вмісту, кількість посилань, заголовок title, наявність у sitemap. Щоквартальний аудит потрібен для перевірки системних аспектів, але не повинен бути єдиним засобом контролю.
16.6Технічний борг має ціну втрачених можливостей
Виправлення, яке заощаджує ресурси пошукового робота, але не впливає на виявлення, індексування чи показ цінних сторінок у результатах пошуку, може бути бажаним, але необовʼязковим. Натомість повільне створення sitemap для щоденного асортименту зі 100k позицій може спричиняти реальні втрати можливостей. Я завжди формулюю проблему через очікуваний результат: «скоротити кількість непотрібних завантажень на 3 млн на день і зменшити затримку виявлення нових товарів», а не «прибрати параметри».
16.7Інструменти — це датчики, а не судді
Screaming Frog, Sitebulb, інструмент аудиту Ahrefs, Botify та Oncrawl бачать різні представлення сторінок і застосовують власні правила. Я не переношу їхні оцінки серйозності в план робіт. Дані сканера, GSC, журналів, сервера, браузера та бізнес-каталогу мають бути зведені в одну модель. Найважливіше питання: чи існує дефект для Googlebot і чи стосується він цінної URL.
16.8Результат технічного аудиту
Мій результат роботи — не PDF на 150 сторінок. Це таблиця системних проблем: механізм, уражений шаблон, кількість уражених URL, докази, ризик для бізнесу, кроки для відтворення, рекомендоване виправлення, відповідальний, трудовитрати, запит для перевірки, ризик відкату. До неї можна додати додаток із необробленими результатами перевірок. Команда розробки повинна мати змогу відтворити проблему без перекладача з мови SEO.
16.9Що ми знаємо точно
Послідовність обробки сторінок у пошуку охоплює виявлення, сканування, відтворення, індексування та показ у результатах пошуку; Search Essentials визначає мінімальні технічні вимоги; Google має окремо задокументовані засоби керування правилами для роботів, кодами стану, канонічними URL, hreflang, структурованими даними та перенесенням сайтів. Офіційної «оцінки технічного стану» від Google не існує. Будь-яка оцінка 92/100 — це метрика інструмента.
Джерела до глави 16
- Google Search Central. Crawling and indexing overview. https://developers.google.com/search/docs/crawling-indexing
- Google Search Central. Search Essentials. https://developers.google.com/search/docs/essentials
- Google Search Central. Latest documentation updates. https://developers.google.com/search/updates
Це скорочений виклад: у книзі кожна глава має повний розбір, таблиці й приклади. Завантажити книгу або почати зі вступу.