26 июля 2026 г. · 9 мин чтения

Может ли AI сам исправлять техническое SEO: безопасный процесс через pull request

Разбираем, какие технические SEO-ошибки можно поручить AI-агенту и как выпускать исправления через небольшой pull request, тесты и ручное ревью.

AI исправляет техническое SEO вполне предметно: агент способен найти ошибочный canonical, поправить генератор sitemap и открыть pull request с изменениями. Это уже не демонстрация будущего; для типового сайта такую работу можно собрать сегодня. Опасная часть начинается со слова «сам». Одна неверная строка в robots.txt закрывает целый раздел, а массовая замена canonical способна убрать из поиска страницы, которые приносили выручку.

Поэтому разумная цель не в том, чтобы дать модели доступ к продакшену. Лучше поручить ей диагностику, подготовку небольшого изменения и проверяемое объяснение, а решение о слиянии оставить человеку. Pull request здесь нужен не ради модного процесса разработки. Он показывает точный diff, запускает автоматические проверки и сохраняет обсуждение до релиза.

Какие SEO-ошибки агент исправляет достаточно хорошо

Лучше всего автоматизируются задачи с однозначным ожидаемым состоянием:

битая внутренняя ссылка должна вести на существующий конечный URL;
sitemap не должен содержать редиректы, ошибки и закрытые страницы;
canonical должен указывать на согласованную основную версию;
публичная страница должна возвращать ожидаемый код ответа;
в шаблоне не должно быть одинакового title у всех объектов;
служебный URL не должен появляться во внутренней навигации;
после переезда старый адрес должен перенаправлять на соответствующий новый.

Агент полезен и при массовой диагностике. Он может сгруппировать тысячи URL по причине, найти общий шаблон и показать несколько репрезентативных примеров. Это быстрее, чем вручную просматривать выгрузку.

Но формулировка задачи должна содержать критерий. «Исправь SEO» оставляет модели слишком много свободы. «Удали из sitemap URL с ответами 3xx/4xx и добавь тест, который не позволит вернуть их» задаёт проверяемую границу.

Что нельзя отдавать без решения специалиста

Некоторые изменения выглядят техническими, но на самом деле меняют стратегию сайта. Выбор канонической страницы между двумя полезными категориями требует понимания спроса и ассортимента. Массовое закрытие фильтров влияет на охват. Перенос раздела меняет пользовательские маршруты и накопленные сигналы.

Человек должен принимать решение, когда:

непонятно, какой URL считать основным;
страницы похожи, но решают разные задачи;
исправление затрагивает оплату, личный кабинет или юридические документы;
нет надёжной резервной копии и понятного отката;
изменение охватывает тысячи адресов;
бизнес недавно сменил продуктовую структуру;
данные Вебмастера противоречат результатам краулера.

AI может подготовить варианты и последствия. Он не знает, что компания через месяц вернёт снятую услугу или что фильтр /delivery-today/ приносит половину заказов, если этого нет в контексте.

Почему прямой доступ к продакшену — плохая экономия

Автоматическое исправление кажется короче: агент нашёл ошибку, изменил файл и сразу выложил. Из процесса исчезают несколько минут ревью, но вместе с ними исчезает место, где можно заметить неверное предположение.

SEO-сигналы связаны между собой. Агент может изменить canonical в шаблоне карточки, не заметив, что:

sitemap передаёт прежние адреса;
внутренние ссылки ведут на копии;
редирект настроен в обратную сторону;
тестовый и основной домены используют общий конфиг;
правило применяется не к одному типу страниц, а ко всему сайту.

Последствия проявляются не всегда сразу. Страница продолжит открываться для человека, а выпадение из поиска станет заметно после нового обхода. Именно поэтому релиз без diff и журнала изменений плохо подходит для SEO.

Как выглядит безопасный цикл

Рабочий процесс состоит из семи шагов.

1. Зафиксировать исходное состояние

Сохраните список затронутых URL, текущие ответы сервера, canonical, статус индексирования и дату. Для ценного раздела добавьте показы, переходы и целевые действия. Без этой точки команда не сможет доказать, что изменение помогло или навредило.

2. Сформулировать одну гипотезу

Один pull request должен решать одну понятную проблему. Не стоит одновременно менять структуру URL, рендеринг, метаданные и sitemap. Маленький diff проще проверить и откатить.

3. Создать отдельную ветку

Агент работает не в основной ветке. Он получает только нужный репозиторий, ограниченный набор инструментов и минимальные секреты. Доступ к аналитике по возможности остаётся только для чтения.

4. Изменить код и добавить проверку

Исправление системной ошибки должно сопровождаться тестом. Если sitemap раньше включал редиректы, тест собирает карту и падает при появлении ответа 3xx. Если canonical строился из неправильного домена, тест проверяет несколько типов страниц.

5. Открыть pull request

В описании нужны причина, список затронутых шаблонов, примеры URL, результаты проверок и порядок отката. GitHub позволяет оставлять комментарии к конкретным строкам, запрашивать изменения и требовать одобрение до слияния. Это делает решение видимым для SEO-специалиста и разработчика.

6. Проверить превью или тестовую среду

Автоматические тесты не показывают всё. Откройте страницы как пользователь и как робот, проверьте HTML, мобильную версию, ссылки и ответы сервера. Для массового шаблона возьмите популярную страницу, новый объект, обычный пример и пограничный случай.

7. Выпустить и перепроверить

После слияния повторите технические проверки в рабочей среде. Затем дождитесь обхода и следите за Вебмастером. Код может работать правильно, а поисковый эффект проявится позже.

Какие проверки запускать до слияния

Минимальный набор зависит от сайта, но для публичного раздела полезны следующие условия:

Проверка	Что предотвращает
Все страницы sitemap отвечают `200`	карты с редиректами и ошибками
URL в sitemap канонические	передача поиску противоречивых адресов
Canonical абсолютный и доступный	ссылки на пустые или тестовые домены
Закрытые страницы отсутствуют в sitemap	конфликт директив
Ценные URL доступны из внутренних ссылок	страницы-сироты
`robots.txt` возвращает `200`	случайно недоступные правила
Нет цепочек перенаправлений	лишние обходы и задержки
Основной текст есть в итоговом HTML	пустые оболочки JavaScript

Проверка не должна просто сообщать «найдено 143 проблемы». Она должна завершать сборку с ошибкой, когда нарушено правило, важное для релиза. Для спорных случаев лучше отчёт и ручное решение.

Пример: исправление sitemap

Представим магазин, где после удаления товара URL начинает перенаправлять на категорию, но остаётся в sitemap. Агент находит 640 таких адресов. Плохое решение — удалить их из готового XML вручную: следующий запуск генератора вернёт всё обратно.

Хороший pull request меняет источник:

генератор выбирает только опубликованные канонические объекты;
проверка собирает sitemap на тестовых данных;
тест убеждается, что удалённый товар и редирект отсутствуют;
описание PR содержит примеры старых URL;
после релиза карта проверяется повторно.

Здесь AI экономит время на поиске общей причины и подготовке кода. Архитектурное решение всё равно проверяет разработчик, знакомый с каталогом.

Пример: canonical, который нельзя чинить массово

Краулер обнаружил, что страницы фильтров указывают canonical на категорию. Агент может решить, что все фильтры — дубли, и предложить редирект. Но часть фильтров имеет собственный спрос, уникальный ассортимент и внутренние ссылки из навигации.

До изменения нужна таблица: URL, запросы, показы, отличие ассортимента, наличие уникального текста, внутренняя роль. После неё адреса разделяются на полезные посадочные и технические комбинации. Только вторая группа получает общее правило.

Это хороший пример границы автоматизации. Код простой; решение сложное.

Как Система связывает SEO-агента и разработку

Платформа «Система» позволяет SEO-агенту превратить сигнал из Вебмастера или технического обхода в задачу с примерами страниц и критерием приёмки. Агент разработки получает контекст, меняет нужный шаблон и готовит pull request. Редактор подключается, если исправление затрагивает текст или структуру ответа.

В обычной связке из краулера, таблицы, чата и GitHub часть контекста теряется: разработчик видит строку «поправить canonical», но не знает, какие запросы и страницы стоят за решением. Система хранит наблюдение, гипотезу, изменение и результат в одной цепочке.

Она не должна автоматически сливать рискованные SEO-правки. Для массовых изменений, удаления URL и правил обхода нужен человек с правом остановить релиз. Преимущество Системы в том, что ручное решение принимается по подготовленным данным, а не заменяется бесконтрольной автоматикой.

Права доступа, без которых процесс опасен

Агенту не нужны пароль от регистратора, полный доступ к продакшену и возможность обходить защиту ветки. Выдавайте минимальные права:

чтение аналитики и Вебмастера там, где это возможно;
запись только в рабочую ветку;
запрет прямого push в main;
обязательные проверки и ревью владельца кода;
отдельные секреты для тестовой среды;
журнал действий.

Защита основной ветки должна действовать и для автоматического автора. Исключение «это же наш агент» уничтожает смысл контроля.

Как оценить эффект после релиза

Сразу после выпуска проверьте код ответа, конечный HTML, robots.txt, sitemap и canonical. Через несколько дней или недель, в зависимости от частоты обхода, смотрите статус страниц в Вебмастере.

Для каждого изменения заранее выберите метрику:

сократилось число ошибочных URL в sitemap;
нужная версия стала канонической;
исчезла цепочка редиректов;
выросла доля проиндексированных полезных страниц;
восстановились показы у раздела;
не ухудшились конверсии и навигация.

Позиции могут колебаться по другим причинам, поэтому не приписывайте весь рост одному техническому PR. Сначала докажите, что исправлена сама ошибка.

С чего начать небольшой команде

Выберите одну повторяемую проверку с низким риском: битые внутренние ссылки или неканонические URL в sitemap. Дайте агенту подготовить отчёт, затем тест и небольшой pull request. Проведите ручное ревью и запишите, где ему не хватило контекста.

После двух-трёх успешных циклов добавляйте новые классы задач. Массовые редиректы, удаление страниц и управление индексированием оставьте на более поздний этап. Цель — не максимальное число автоматических исправлений, а предсказуемый выпуск изменений без потери поискового трафика.

Продолжить диагностику помогут материалы про SEO-аудит специалистом и AI-агентом, про robots.txt для AI-ботов и про сайт, собранный нейросетью.

AI уже может исправлять техническое SEO, если «исправлять» означает готовить проверяемое изменение. Доступ к основной ветке и продакшену ему для этого не нужен. Хороший результат — небольшой diff, зелёные проверки, осмысленное ревью и сохранённая возможность отката.