Проверка SEO-статьи после публикации: технический чек-лист

Проверка SEO-статьи после публикации должна подтвердить не позиции, а корректность самой поставки. Откройте финальный URL и последовательно проверьте: ответ сервера 200, отсутствие неожиданного редиректа, правильный canonical, разрешение на индексирование, уникальные title и meta description, один видимый H1, полный текст, валидный JSON-LD и рабочие внутренние ссылки. Если любой блокирующий пункт не пройден, публикацию нельзя считать завершённой: исправьте шаблон или безопасно откатите только новую запись.

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

Чек-лист рассчитан на SEO-специалистов и небольшие агентства, которые публикуют материалы вручную или через API. Он проверяет доставку уже утверждённого материала, но не заменяет редактуру до релиза и не обещает определённый срок индексации.

Краткие выводы

• Сначала проверяйте доступность и финальный URL, затем поисковые директивы, контент, разметку и ссылки.
• Canonical — рекомендация поисковой системе, поэтому он должен указывать на нужный доступный URL без цепочек и противоречий.
• Для индексируемой статьи критично отсутствие noindex; явная запись index, follow допустима, но не обязательна.
• Один H1 — удобное внутреннее правило приёмки: оно выявляет ситуацию, когда заголовок шаблона продублирован внутри тела статьи.
• Валидный JSON ещё не означает корректную микроразметку: значения должны совпадать с тем, что видит читатель.
• Индексирование, показы и клики контролируют после технической приёмки, а не используют как условие выпуска.

Что относится к проверке после публикации

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

Не смешивайте эти два контроля. Хороший текст может оказаться под noindex, получить canonical на другой материал или потерять половину HTML при передаче. И наоборот, технически безупречная страница может не закрывать поисковый интент. В рабочем редакционном процессе SEO-агентства это две разные контрольные точки с разными ответственными.

Модель пяти слоёв приёмки

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

1. Доставка: HTTP-ответ, финальный URL и отсутствие неожиданного редиректа.
2. Индексируемость: canonical, meta robots, X-Robots-Tag и доступ робота.
3. Представление: title, meta description и единственный H1 из шаблона.
4. Содержимое: полный HTML статьи, обязательные разделы и корректный JSON-LD.
5. Связи: внутренние ссылки, CTA, sitemap и последующий контроль индексирования.

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

Порядок технической приёмки SEO-статьи

1. Зафиксируйте ожидаемый результат

До запроса страницы сохраните четыре значения: ожидаемый URL, title, meta description и минимальный объём основного текста. Если публикация идёт через API, добавьте идентификатор доставки или записи. Такой набор позволяет сравнивать не «похожую страницу», а конкретный результат операции. Для интеграций полезно заранее определить идемпотентность, повторные попытки и проверку ответа — эти принципы разобраны в схеме API-публикации SEO-статей.

2. Проверьте HTTP-ответ и финальный адрес

Новый публичный URL должен открываться без авторизации и возвращать успешный ответ. Для обычной HTML-статьи базовый ожидаемый статус — 200. Проверьте также адрес после всех перенаправлений: опечатка в slug, лишний префикс языка или редирект на список блога могут скрыться за визуально «открывшейся» страницей.

Если новый URL сразу перенаправляет на другой материал, остановите выпуск и выясните причину. Допустимый редирект должен быть заранее запланирован, а не появляться из-за конфликта маршрутов или занятого slug.

3. Сверьте canonical и индексируемость

Для самостоятельной статьи canonical обычно должен совпадать с финальным абсолютным URL. Яндекс называет rel="canonical" рекомендацией и может не учитывать её, если каноническая страница недоступна, отличается по содержанию или образует цепочку. Это описано в официальной справке о каноническом адресе страницы.

Затем проверьте meta robots и HTTP-заголовок X-Robots-Tag. На индексируемой странице не должно быть noindex. Учитывайте все директивы вместе: более строгая настройка на уровне заголовка способна отменить ожидаемое поведение шаблона. Список поддерживаемых правил есть в справке Яндекса о метатегах для поисковых роботов.

4. Проверьте head и главный заголовок

В исходном или отрендеренном HTML должны присутствовать непустые title и meta description. Сравните их с утверждёнными значениями и убедитесь, что CMS не подставила общий текст раздела. Поисковая система может сформировать сниппет из разных частей страницы, но корректные title и description помогают ей понять желаемое представление. Яндекс отдельно описывает, как формируются заголовок и описание в поиске.

Внутреннее правило «один H1» удобно для автоматической проверки. Шаблон блога обычно выводит H1 из поля title, поэтому тело статьи не должно содержать ещё один H1. Одновременно сравните текст видимого заголовка с заявленной темой: технически валидная, но чужая запись означает ошибку связывания данных.

5. Убедитесь, что основной контент не потерян

Считайте длину текста внутри контейнера статьи после удаления HTML, а не длину всей страницы вместе с меню и футером. Проверьте наличие обязательных разделов, таблицы или чек-листа и FAQ. Такой контроль ловит обрезанный ответ API, неправильное экранирование и ситуацию, когда CMS сохранила HTML как текст.

Дополнительно запретите в теле script, style, iframe и формы, если они не входят в согласованный формат. Для автоматизированного потока полезен белый список разрешённых тегов: так опасная или несовместимая конструкция не попадёт в шаблон незаметно.

6. Разберите и сопоставьте JSON-LD

Найдите блок application/ld+json, разберите его как JSON и проверьте тип Article или BlogPosting. Headline, description, основной URL, язык, автор, издатель и даты должны соответствовать опубликованной странице. Дата изменения не должна быть раньше даты публикации, а mainEntityOfPage — вести на текущий canonical.

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

7. Проверьте внутренние ссылки и CTA

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

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

Таблица приёмочных проверок

Что автоматизировать, а что оставить редактору

Скрипт надёжно проверяет HTTP-статус, финальный URL, canonical, robots, число H1, длину текста, синтаксис JSON-LD и ответы по ссылкам. Эти условия однозначны и подходят для запуска сразу после сохранения записи.

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

Результат удобно хранить как короткий протокол: время проверки, URL, версия материала, пройденные пункты и причина отката. Тогда повторный запуск не создаёт дубли, а команда видит, на каком именно этапе возникла ошибка.

Типичные ошибки после публикации

• Проверять только внешний вид в браузере и не смотреть canonical, robots и JSON-LD.
• Считать любой редирект успешной публикацией, не сверяя финальный URL.
• Искать H1 по всей странице и принимать заголовок блока «Похожие статьи» за заголовок материала.
• Измерять длину вместе с меню, комментариями и футером вместо контейнера статьи.
• Проверять JSON-LD только на синтаксис и не сравнивать headline, description и даты с видимым контентом.
• Требовать немедленных показов и позиций: это внешние отложенные сигналы, а не критерии технической поставки.
• При сбое удалять или менять старые материалы вместо отката записи, созданной текущей операцией.

Когда проверять индексирование

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

Если страница долго не появляется в поиске, сначала перепроверьте доступность, robots, canonical, качество и внутренние ссылки. Не публикуйте копию с новым slug: это создаёт конкурирующие URL и усложняет диагностику.

FAQ

Нужно ли явно ставить index, follow?

Нет. Для обычной HTML-страницы это поведение используется по умолчанию. В приёмке важнее убедиться, что в meta robots и X-Robots-Tag нет noindex или других неожиданных ограничений. Явный index, follow можно оставить как понятную настройку шаблона.

Можно ли считать публикацию успешной, если URL возвращает 200?

Нет. Статус 200 подтверждает только доступность ответа. Страница всё ещё может иметь canonical на другой URL, noindex, пустой title, дублированный H1, обрезанный контент или неверную микроразметку.

Обязан ли canonical совпадать с текущим URL?

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

Сколько ждать индексацию перед откатом?

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

Что делать, если одна внутренняя ссылка ведёт через редирект?

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

Заключение

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

Если вы хотите сократить ручные операции при подготовке SEO-материалов и выстроить управляемый контентный поток, изучите возможности SerpJet.