У більшості команд уже є звіт про позиції в Google. Це вкладка «Ефективність» у Search Console, відсортована за кліками й знята скриншотом у слайд. У ній видно позиції. У ній не видно, що змінилося, чому змінилося і що кому з цим робити.
Цей процес вирішує задачу за один підхід. Ви задаєте набір запитів, передаєте Codex письмовий контракт звіту й далі отримуєте звіт однакової форми щотижня. Перше складання займає близько 90 хвилин. Кожен наступний запуск — менше десяти.
Увесь процес: сирі вивантаження на вході, один звіт фіксованої форми на виході й одне рішення людини в кінці.
Що у вас буде на виході
Для кого це: для всіх, хто відповідає за звітність щодо сайту й уже має доступ до Search Console. Бути розробником не обов'язково, але потрібне місце для файлів, яке Codex зможе читати.
Що залишиться на руках: збережений шаблон звіту, письмовий файл інструкцій, якого Codex дотримується щоразу, і один готовий звіт за реальний тиждень.
Що потрібно заздалегідь: підтверджений ресурс у Search Console, список із 20–50 запитів, які вам справді важливі, Codex із доступом до папки проєкту й право на читання репозиторію вашого сайту, якщо захочете просунуту версію.
Критерій готовності: ви можете віддати звіт людині, яка не займається SEO, і вона скаже, на які три запити дивитися й чому.
Час: близько 90 хвилин на перше складання, менше 10 хвилин на запуск після нього.
Чому звіт «Ефективність» — не звіт про позиції
Search Console дає чотири стовпці: кліки, покази, CTR і середня позиція. Це таблиця вимірювань. Звіт про позиції має відповідати на інший набір питань, і сигнали 2026 року зробили цей розрив ширшим, ніж раніше.
Експертне опитування Zyppy, опубліковане 9 вересня 2026 року, зібрало 13 665 точок даних від 131 практика. Сигнали кліків і поведінки — 29,4%, сигнали бренду — 27,0%, технічне здоров'я SEO — 17,5%. Два з трьох сигналів, які обійшли технічне здоров'я, у стовпці позиції не видні. Розбір того, що змінюють ці цифри, є в окремому практичному посібнику, але для звітності висновок короткий: якщо ваш звіт показує лише позиції, ви звітуєте про сигнал, який зсунувся найменше.
Саме цей розрив закриває Codex. Він не скаже, чому Google щось змінив. Він збере докази зміни достатньо однаково, щоб це могли сказати ви.
Перед початком: чотири рішення
Ухваліть їх до того, як щось напишете, бо зміна заднім числом означає перескладання звіту.
- Набір запитів. 20–50 запитів, згрупованих у дві-три корзини за логікою бізнесу. «Продукт», «порівняння», «підтримка» працює краще, ніж «висока частота / середня / низька».
- Вікно порівняння. Порівнюйте останні 28 днів із попередніми 28 днями. Коротші вікна шумлять, довші ховають ту зміну, яку ви шукаєте.
- Поріг. Вирішіть, що вважається вартим згадки. Запит, що зсунувся більш ніж на п'ять позицій, або покази, що змінилися більш ніж на 30% при плоских кліках, — робочі значення за замовчуванням.
- Місце зберігання. Одна папка, одне правило найменування.
reports/ranking/YYYY-MM-DD.mdплюс підпапкаdata/для сирих вивантажень. Codex потребує постійного місця для запису.
Крок 1: вивантажте сирі дані
Відкрийте Search Console, виберіть ресурс і перейдіть до «Ефективності». Поставте діапазон 56 днів, щоб порівняння 28 на 28 було можливе з одного вивантаження, потім кнопкою експорту завантажте CSV вкладки «Запити».
Те саме зробіть для «Сторінок», а для «Пристроїв» — якщо збираєтеся звітувати про різницю між мобільними й десктопом.
Очікуваний результат: три CSV-файли в data/, в імені — дата вивантаження.
Перевірка якості: відкрийте CSV із запитами й переконайтеся, що перший рядок даних — не запит зі словом "anonymous". Search Console приховує рідкісні запити, і інакше ці рядки потраплять у звіт як безіменні рухи.
Якщо не вийшло: якщо вивантаження обрізане, діапазон заширокий для ліміту рядків. Вивантажте вікна по 28 днів окремо, а склеїти їх доручте Codex.
Крок 2: напишіть контракт звіту
Це крок, який вирішує, чи доживе процес до четвертого тижня. Покладіть контракт у файл, який Codex читає щоразу: AGENTS.md у корені проєкту або окремий файл інструкцій у папці звітів.
У контракті потрібні п'ять речей і більше нічого:
Блок контракту | Що писати | Чому це важливо |
|---|---|---|
Вхідні дані | Точні шляхи до файлів і правило діапазону дат | Не дає агенту вигадати вікно |
Пороги | Ваші межі, у числах | Перетворює таблицю на рішення |
Форма виводу | Три розділи, у цьому порядку | Зберігає порівнюваність 30-го тижня з 1-м |
Правила впевненості | Що писати, коли дані не пояснюють зміну | Запобігає впевненій нісенітниці |
Межі | Що агент робити не повинен | Лише читання, поки ви йому не довіряєте |
Робоча версія виглядає так:
## Контракт звіту про позиції
Вхід: data/queries-*.csv, data/pages-*.csv
Вікно: останні 28 днів проти попередніх 28. Обидві дати вказувати в шапці звіту.
Повідомляти лише три речі:
1. Запити, що зсунулися: будь-який запит зі зсувом понад 5 позицій, або
покази, що зросли більш ніж на 30% при плоских кліках, або будь-який
запит, що випав із топ-10.
2. Імовірне пояснення: використовувати лише дані з файлів. Якщо файли не
пояснюють рух, написати "цими даними не пояснюється".
3. Перевірити наступного тижня: один рядок на позначений запит, з точною
назвою сторінки або запиту для перевірки.
Ніколи не називати причину, на яку не можна вказати в даних. Ніколи не
рекомендувати зміни на сайті. Ніколи не редагувати файли поза reports/ranking/.Очікуваний результат: один файл інструкцій, закомічений або збережений поряд із даними.
Перевірка якості: прочитайте контракт уголос. Якщо будь-який рядок можна без правок застосувати до іншого сайту, він занадто розпливчастий, щоб щось обмежувати.
Якщо не вийшло: якщо Codex продовжує додавати розділи, форма виводу недостатньо конкретна. Назвіть три заголовки рівно так, як хочете їх бачити.
Анатомія звіту. Підвал зі списком точно використаних файлів — та частина, якій перевіряльники довіряють найбільше, і та, яку більшість шаблонів пропускає.
Крок 3: згенеруйте перший звіт
Вкажіть Codex на папку й попросіть один звіт за контрактом. Просіть файл, а не відповідь у чаті: так результат можна перевірити й порівняти за дифом.
На першому запуску ви й дізнаєтеся, як насправді виглядають ваші дані. Закладіть два-три кола правок. Це нормально, і це найдешевша частина всього процесу.
Очікуваний результат: reports/ranking/YYYY-MM-DD.md із шапкою, трьома розділами й підвалом зі списком точно використаних файлів.
Перевірка якості: візьміть два позначені запити й перевірте числа руками в Search Console. Збіглося — конвеєр справний. Не збіглося — зупиніться й полагодьте крок із даними. Не зневаджуйте аналіз поверх зламаного входу.
Якщо не вийшло: найчастіше розходяться дати вивантаження й контракту. Фіксуйте обидві дати в шапці щоразу, щоб зсув на два дні не перетворював тихо плоский місяць на обвал.
У першій моїй версії звіт показав одинадцять запитів, що зсунулися, за тиждень, коли майже нічого не рухалося. Контракт був гаразд, а вивантаження — ні. Файл на 30 днів, порівняний із вікном у 28 днів, перетворив два пропущені дні на обвал по всьому сайту. Тепер контракт відмовляється запускатися, якщо діапазони не збігаються, і цей збій більше не повертався.
Крок 4: додайте рядок, який агент написати не може
До кожного звіту входить один людський абзац: що ми випустили, змінили або зламали за тиждень.
Це не оздоблення. Це найшвидший спосіб упіймати агента, який приписує ваш власний реліз оновленню алгоритму. Коли звіт каже, що просіла група сторінок продуктів, а ваша нотатка каже, що у вівторок змінили шаблон, коло пояснень звужується відразу.
Очікуваний результат: два-три речення на початку звіту, написані людиною.
Перевірка якості: якщо нотатка й розділ рухів суперечать одне одному, ця суперечність — найцінніший рядок у звіті. Залиште її на видноті, а не згладжуйте.
Крок 5: перевірте перед надсиланням
Пройдіть ці три перевірки, перш ніж звіт піде з вашого столу.
- Дати. Обидва вікна вказані в шапці й збігаються з вивантаженням.
- Дві вибіркові перевірки. Два позначені запити перевірені вручну.
- Одна перевірка на суперечність. Чи не посилається якесь заявлене пояснення на дані, яких немає у списку файлів унизу?
Якщо всі три пройдено, звіт безпечно показувати. Це чернетка вашого судження, а не заміна йому.
Просунутий шлях, коли будете готові
Перші чотири тижні ведіть процес руками. Автоматизуйте лише після того, як двічі виправили один і той самий клас помилок.
Далі покращення йдуть по наростаючій:
- Поставте запуск на розклад. Щотижневий запуск за розкладом напише звіт до того, як ви відкриєте ноутбук. Людський абзац залиште обов'язковим полем, щоб звіт без нього не міг вийти.
- Зберігайте знімки в системі контролю версій. Кожен запуск стає комітом. Диф між двома тижнями читається швидше за будь-який із двох звітів.
- Додайте другий ресурс. Запити конкурентів або бренду живуть в окремому звіті з тим самим контрактом, а не підмішуються в основний.
- Додайте один зовнішній сигнал. Перевірка брендового пошуку чи частки відповідей робить брендовий сигнал з опитування 2026 року вимірюваним, а не теоретичним.
Що автоматизувати не варто: крок із рекомендаціями. У момент, коли агент починає пропонувати зміни на сайті, ви перейшли від звітності до публікації, і навантаження на перевірку зростає швидше, ніж економиться час.
Усунення несправностей
Симптом | Імовірна причина | Що робити |
|---|---|---|
Усі запити виглядають як ті, що впали | Зсув діапазонів дат між вивантаженнями | Зафіксувати обидва вікна і в контракті, і в шапці |
Звіт порожній | Пороги занадто суворі для вашого рівня трафіку | Знизьте поріг за показами раніше, ніж поріг за позицією |
Ті самі п'ять запитів щотижня | Набір запитів завузький | Додайте в корзини довгохвості та порівняльні запити |
Рух без пояснення | Нормально для низькочастотних запитів | Залиште вивід «цими даними не пояснюється» і йдіть далі |
Числа розходяться з Search Console | Незбіг ресурсу або фільтра у вивантаженні | Вивантажуйте завжди з одного ресурсу й одного набору фільтрів |
Підтримуйте процес
Три звички збережуть його корисним і після першого кварталу.
Переглядайте набір запитів щокварталу. Звіт, який слідує за пріоритетами минулого року, — це урок історії, а не звіт про позиції.
Перечитуйте контракт, коли змінюється Search Console. Google періодично оновлює інтерфейс звіту «Ефективність» і поля вивантаження. Якщо поле зникло, контракт треба правити того ж дня.
Зберігайте старі звіти. Порівняти звіт цього кварталу з тим самим кварталом минулого року — єдиний дешевий спосіб відділити реальне падіння від сезонності.
Часті запитання (FAQ)
Потрібен саме Codex? Ні. Процес працює з будь-яким агентом, який уміє читати файли, запускатися за розкладом і писати результат, який можна перевірити. Codex добре підходить, коли сайт уже лежить у репозиторії: звіт стає комітом, який можна порівняти.
Можна обійтися лише безкоштовними інструментами? Так. Увесь процес працює на безкоштовних даних Search Console плюс агент. Платний трекер позицій потрібен лише тоді, коли потрібні позиції конкурентів або позиції, яких не видно у вашому власному ресурсі.
Чим це відрізняється від звіту «Ефективність» у Search Console? Той звіт показує таблицю. Цей процес видає рішення: які запити перетнули поріг, що дані пояснюють, а що ні, і що перевіряти наступного тижня. До того ж він залишає запис, а інтерфейс — ні.
А якщо в сайту зовсім мало трафіку? Знизьте поріг за показами й порівнюйте 28 днів із тими самими 28 днями минулого року, а не з попередніми 28. Сайти з малим обсягом отримують більше сигналу з річних порівнянь, ніж із тижневих.
Чи включати у звіт AI Overviews або AI-цитування? Якщо хочете, додайте окремий розділ зі своїм контрактом. Тримайте його поза звітом про позиції: джерела й спосіб вимірювання там інші, і змішування робить обидва менш читабельними.
Автор: Leo Harrington, перекладач SEO-аналітики для понад 500 звітів для керівництва в Auspia. Leo пише про те, як перетворювати пошукові дані на звіти, за якими може діяти нефахівець.
