Правки некому внедрить: почему я вношу их сам

Про поисковое продвижение обычно спорят, какие правки нужны сайту. На практике чаще ломается другое: правки, о которых все договорились, не доезжают до сайта. В списке причин, по которым продвижение не даёт результата, этот пункт стоит четвёртым — и он единственный, который не зависит ни от ниши, ни от возраста домена, ни от алгоритмов поисковика. Он зависит только от того, кто и когда внесёт изменения.

Где обычно ломается продвижение

Картина повторяется от проекта к проекту. Аудит сделан, задания переданы, дальше они уходят в очередь: у подрядчика по разработке свои приоритеты, у штатного программиста текущие задачи бизнеса, у конструктора сайтов ограничения, из-за которых часть правок физически внести нельзя. Проходит квартал: в отчётах работы есть, на сайте изменений нет, в выдаче тоже.

Разрыв здесь организационный, а не технический. Тот, кто планирует правки, обычно не имеет доступа к коду. Тот, у кого доступ есть, не обязан понимать, зачем менять заголовок, который «и так нормальный», и почему адрес страницы нельзя поменять без перенаправления со старого. Подробнее этот механизм разобран в причине правки некому выкатить.

Что такое доработка сайта с ИИ и чем она не является

Сразу о том, чего в этом нет. Это не «нейросеть соберёт сайт за пять минут» и не замена разработчику в сложном проекте. ИИ-инструменты разработки ускоряют реализацию: то, что раньше означало неделю ожидания в чужой очереди, занимает часы работы. Решение о том, что менять, проверка результата и ответственность за него остаются за мной — ИИ здесь инструмент, а не исполнитель.

Практическая разница для заказчика одна: цикл «заметил — исправил — проверил» замыкается внутри одного человека, а не между тремя. Исчезает не работа, а передача задачи из рук в руки — вместе с недопониманием, которое на этой передаче возникает.

Какие правки я закрываю сам

• Метаданные и заголовки. Title и description, H1, порядок и вложенность заголовков на странице.
• Структура и адреса. Новые разделы, перенос страниц на новые адреса с постраничными перенаправлениями, чтобы накопленный вес не терялся.
• Шаблоны. Блоки, которые выводятся сразу на десятках страниц: хлебные крошки, перелинковка, карточки, подвал.
• Микроразметка. Schema.org для организации, услуг, статей и хлебных крошек — и проверка её валидаторами, а не «на глаз».
• Техническая часть. robots.txt, карта сайта, канонические адреса, скорость загрузки, корректные коды ответа.
• Контентные блоки. Новые страницы, таблицы, блоки вопросов и ответов, формы обратной связи.
• Аналитика. Счётчики, цели, разметка ссылок, чтобы в отчёте было что показывать.

Чего в этом списке нет: бизнес-логики интернет-магазина, интеграций с учётными системами, личных кабинетов и всего, что живёт в серверной части крупного проекта. Там нужен разработчик проекта, и правильный вариант — работать вместе с ним, а не вместо него.

Как это выглядит на одном заходе

Пример — правка на этом сайте 27 сентября 2026 года. Задача звучала в одну строку: убрать с сайта телефонный номер.

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

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

Весь заход, от постановки задачи до проверки на боевом сервере, уложился в один рабочий подход в тот же день. Проверка при этом была не «посмотрел глазами»: запросы, сделанные с самого сервера, показали, что ни номера, ни телефонных ссылок не осталось ни на одной из восьми страниц, а разбор микроразметки — что поле с телефоном исчезло из всех сущностей.

Почему на чужом сайте это занимает больше времени

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

• Сначала разбор. Прежде чем менять, нужно понять, как устроен вывод: где лежит шаблон, что подставляет плагин, а что вписано руками в конкретную страницу.
• Одинаковое сделано по-разному. На сайтах, которые росли годами, один и тот же блок нередко собран тремя способами в разных разделах — правка в одном месте меняет не всё, и это выясняется только проверкой.
• Нужна копия для проверки. Правки шаблонов проверяются не на живом сайте, а на копии, и её сначала надо поднять.

Поэтому первые задачи на новом проекте идут медленнее последующих: разбор делается один раз, дальше скорость выравнивается. Честный ориентир на старте — не «правка за час», а «первая неделя уходит на то, чтобы правки стали быстрыми».

Почему это не превращается в «сломал и не заметил»

Скорость сама по себе опасна: чем быстрее вносятся правки, тем легче незаметно что-то сломать. Поэтому правки обставлены проверками, которые срабатывают до и после выкладки.

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

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

Чего я не перекладываю на ИИ

Стратегию: что продвигать, под какие запросы и в каком порядке. Цифры в отчёте — они снимаются из панелей и проверяются, а не пересказываются. Переписку: на вопросы отвечаю я сам и своими словами.

С текстами то же правило: ИИ помогает собрать черновик и разобрать структуру, но факты, цифры и формулировки я проверяю сам. В опубликованное не уходит то, что нельзя подтвердить источником, — отвечаю за текст я, а не модель.

Если внедряет ваш разработчик: каким должно быть задание

Отдавать внедрение на свою сторону — нормальный вариант, особенно если у сайта есть штатный разработчик и устоявшийся порядок выкладки. Но тогда результат зависит от того, насколько задание можно выполнить, не додумывая. Признаки задания, которое дойдёт до сайта без потерь:

• Одна правка — один пункт, с точным адресом страницы и парой «было → стало». Разработчику не нужно понимать поисковое продвижение, ему нужно понимать, что именно поменять.
• Готовый текст, а не указание. «Оптимизировать заголовок» — не задание. Задание — готовая строка, которую можно скопировать.
• Отдельным блоком — чего менять нельзя: адреса страниц, шаблон вывода, разметку. Половина потерь трафика после доработок случается там, где правку сделали шире, чем просили.
• Приоритет и срок у каждой строки. Задание без приоритета растворяется в общем списке задач и всплывает через квартал.
• Проверка после внедрения — на стороне того, кто задание писал. Не «внедрили и закрыли», а «внедрили, проверили на живом сайте, что стало как задумано».

Последний пункт — тот самый, из-за которого работы в отчёте расходятся с реальностью на сайте. Написанное задание и внедрённое задание — разные события, и проверять нужно второе.

Что спросить у подрядчика про внедрение

• Кто вносит правки: вы, я или мой разработчик — и что произойдёт, если он будет занят?
• Что вы делаете, если правку внести нельзя из-за ограничений платформы: ищете обходной путь или пункт просто останется невыполненным?
• Кто проверяет результат после внедрения и по каким признакам?
• Что происходит, если правка ухудшила показатели: как это будет замечено и за чей счёт откат?

Ограничения, о которых стоит знать заранее

• Чужая CMS бывает закрытой. На части конструкторов нельзя менять адреса страниц, шаблоны и разметку. Это выясняется до начала работ, а не в процессе, и иногда честный ответ — «на этой платформе половина плана невыполнима».
• Нужны доступы. Правка на сайте — это доступ к админке или к файлам. Если внутренние правила компании такого не допускают, схема остаётся прежней: я готовлю задание, внедряет ваш разработчик.
• Бэкап до правки обязателен — и желательно проверенный восстановлением, а не просто существующий.
• Ответственность делится. Если у сайта есть свой разработчик, правки согласуются с ним. Два человека, молча правящие один сайт, — худший из вариантов.

Что с этим делать

Проверить своё узкое место можно до любого договора: попросите поменять title одной страницы и засеките, сколько дней это займёт. Если больше недели — задача не в SEO, а в очереди на внедрение, и никакой аудит этого не исправит.

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

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