Шаблон запиту на технічну SEO-зміну

Форма запиту на зміну (для заповнення)

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

Запит на технічну SEO-зміну

Один запит - одне виправлення. Якщо потрібні дві зміни, напишіть два запити й зв'яжіть їх.

Трекер для кількох запитів

Наступний крок

• Відповідальний: [ім'я] - дія: [оцінити й запланувати] до [дата]
• Рецензент: [ім'я] - дія: провести перевірки приймання після релізу

Перевірка готовності

• Кожне поле вище заповнене або позначене «н/з» з поясненням.
• Посилання на докази відкриваються і для людей поза SEO-командою.
• Кожен критерій приймання має чіткий результат: пройдено або не пройдено.
• У кроках відкату названо людину й умову для відкату.
• Розробник прочитав запит і погодив обсяг робіт.

Як оформити докази

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

Що додати

• Приклади URL: 3-5 проблемних URL, щонайменше один на кожен зачеплений шаблон, плюс один справний URL для порівняння.
• Експорт сканування: відфільтровані рядки (URL, статус, поле з помилкою) і дата сканування. Дайте посилання на файл, а не вставляйте 500 рядків.
• Звіт Search Console: назва звіту, рядок із проблемою, приклади URL, які він показує, і дата, коли ви дивилися.
• Вихідний HTML: відповідь сервера, щоб показати, що є в HTML до виконання JavaScript.
• Відрендерений HTML: у «Перевірці URL-адреси» (URL Inspection): «Перевірити URL у реальному часі» (Test live URL), далі «Переглянути перевірену сторінку» (View tested page), вкладка HTML.
• Заголовки або кроки редиректу, якщо проблема в коді статусу, X-Robots-Tag чи редиректі.

Кроки для відтворення

1. Відкрийте [URL].
2. Перегляньте [вихідний код / заголовки відповіді / відрендерений HTML].
3. Очікувано: [що має бути].
4. Фактично: [що є].

Інструменти, які допоможуть

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

Скористайтеся Get Source Code of Webpage, щоб отримати вихідний HTML і HTTP-заголовки, а Redirect Checker експортує кожен крок редиректу в CSV або JSON для тікета.

Зверніть увагу: перегляд коду показує HTML до виконання JavaScript. Щоб побачити, що відрендерив Google, використовуйте «Перевірку URL-адреси» (URL Inspection) у Search Console.

Вплив і пріоритет

Коли використовувати: Поясніть, чому це виправлення варте часу в спринті, на власних даних, а не на запозичених галузевих відсотках.

Три чесні цифри

1. Кількість проблемних URL: порахуйте їх за даними сканування, окремо для кожного шаблону.
2. Частка трафіку: у звіті «Ефективність» (Performance) у Search Console додайте фільтр «Сторінки», «URL-адреси, що містять» [фрагмент URL]. Запишіть кліки за останні [3 місяці] порівняно з усім сайтом.
3. Сторінки з доходом чи лідами: за власною аналітикою позначте, чи ці сторінки конвертують, і які саме.

Пишіть так

«[340] URL категорій мають [проблема]. За даними Search Console, вони отримали [x]% органічних кліків за останні [3 місяці]. [Усі / деякі] з них приносять дохід.»

Чого не писати

• Обіцяне зростання позицій чи трафіку. Заздалегідь цього знати неможливо.
• Галузеві середні показники без джерела.
• «Санкції Google» там, де йдеться про звичайну помилку індексації чи сканування.

Як визначити пріоритет

Один раз погодьте шкалу з техлідом розробки і далі використовуйте її, щоб не узгоджувати пріоритет заново в кожному тікеті.

Критерії приймання

Коли використовувати: Перетворіть «виправте SEO-проблему» на перевірки, які будь-хто в команді може провести й позначити як пройдені чи ні.

Якими мають бути критерії

• Видимі: тег, заголовок, код статусу чи HTML-елемент, який можна побачити.
• Конкретні: називають URL або маску URL для перевірки.
• Однозначні: пройдено або не пройдено, без «стало краще».
• Включають те, що не має змінитися.

Формат «Дано / Коли / Тоді»

• Дано [URL на production з шаблоном X], коли [Googlebot або браузер запитує його], тоді [відповідь 200 і жодного noindex у HTML чи заголовках].
• Дано [URL на staging], коли його запитують, тоді [noindex на місці].

Готові перевірки

За словами Search Console, перевірка зазвичай триває до двох тижнів, а може й довше, тож вкажіть у запиті дату повторної перевірки.

План відкату

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

Заповніть до релізу

• Як скасувати: [відкотити коміт / вимкнути прапорець / відновити попередній robots.txt]. Додайте до запиту попередній файл чи налаштування.
• Хто вирішує: [ім'я], на зв'язку в день релізу.
• Умова для відкату: [приклади URL віддають 5xx, редирект веде не туди, staging стає доступним для індексації, ламається верстка].
• Період спостереження: [перші 24 години / 7 днів], за допомогою [сканування, серверних логів, Search Console].
• Після відкату: знову відкрийте запит і додайте до доказів, що пішло не так.

Ризиковані зміни, для яких план потрібен завжди

• Правки robots.txt і загальносайтові правила meta robots чи X-Robots-Tag.
• Правила редиректів і зміни структури URL.
• Логіка canonical у спільних шаблонах.
• Зміни рендерингу, наприклад перенесення контенту в клієнтський JavaScript.

Пам'ятайте: noindex працює, лише якщо сторінку не заблоковано в robots.txt. Відкат, який додає блокування в robots.txt, може сховати noindex від Google.

Версія тікета для Jira/Linear

Коли використовувати: Текстовий блок, який можна вставити в Jira, Linear, GitHub Issues чи будь-який трекер, що не підтримує таблиці.

Готовий тікет

• Назва: [SEO] [коротко: виправлення на шаблоні]
• Тип: [Bug / Task] | Пріоритет: [P1] | Мітки: seo, [шаблон]
• Проблема: [одне речення]
• Докази: [приклади URL] | [посилання на експорт сканування] | [звіт Search Console + дата] | [скриншот відрендереного HTML]
• Кроки для відтворення: 1) відкрити [URL] 2) переглянути [код/заголовки] 3) очікувано [x], фактично [y]
• Запропоноване виправлення: [точна зміна і файл/налаштування]
• Поза межами: [чого не чіпати]
• Вплив: [кількість URL, частка кліків, сторінки з доходом] (джерело: [інструмент, період])
• Залежність: [ID тікетів, реліз, доступи]
• Критерії приймання: [ ] [перевірка 1] [ ] [перевірка 2] [ ] [що не має змінитися]
• Відкат: [як] | вирішує: [ім'я] | умова: [сигнал]
• Відповідальний: [розробник] | SEO-рецензент: [ім'я] | Повторна перевірка: [дата]

Поради для трекерів

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

Заповнений приклад (вигаданий магазин туристичного спорядження)

Коли використовувати: Заповнений запит для вигаданого магазину туристичного спорядження, сторінки категорій якого випадково закрили noindex.

Заповнений приклад: сторінки категорій Fernwick Outdoor

Лише приклад. Компанію, людей, URL і цифри вигадано, щоб показати, як виглядає корисна заповнена версія.

Чому це спрацювало

• Докази надійшли з трьох джерел, і вони збігалися: сканування, Search Console і відрендерений HTML.
• Виправленням була одна зміна налаштування, а не переписування теми, тому воно вийшло в наступному релізі.
• Приймання включало перевірку staging, тож виправлення не створило нової проблеми.
• Вплив оцінили за власною часткою кліків магазину, а не навмання.

Наступний крок

Запустіть безкоштовний аудит сайту, щоб знайти подібні проблеми з індексацією разом зі списком проблемних сторінок. Вибірково перевіряйте будь-яку сторінку під час перегляду за допомогою seotools.pro SEO Extension.