Шесть лет в цифрах
Зачем проверять canonical?
В Seo-Gen собраны отдельные проверки для SEO-анализа страницы, индексируемости, индексации в Google, скорости загрузки, HTTP-кодов, редиректов, robots.txt, sitemap.xml, meta robots, canonical и hreflang. Здесь же можно определить CMS сайта и проверить ссылки. Каждый инструмент решает конкретную техническую задачу, поэтому для первичной диагностики не всегда требуется полный SEO-аудит сайта.
Canonical помогает указать предпочтительный адрес среди похожих или дублирующихся страниц. Ошибка в нём может отправлять поисковой системе сигнал в пользу другого URL, хотя продвигаться должна текущая страница.
Canonical нужно проверять после миграции, изменения домена, работы с фильтрами и шаблонными страницами. Он должен соответствовать остальным техническим сигналам сайта.
SEO-анализ страницы
SEO-анализ страницы нужен для первичной проверки отдельного URL. Он помогает собрать основные сведения о документе в одном месте и понять, есть ли очевидные проблемы, которые требуют более глубокой диагностики. Такой анализ удобно запускать перед публикацией, после изменения шаблона, во время проверки новой посадочной страницы или при заметном падении её видимости.
Результат следует рассматривать вместе с другими техническими данными. Нормальный Title сам по себе не гарантирует, что URL доступен поисковой системе, а правильный canonical не решает проблему серверной ошибки. Поэтому SEO-анализ сайта лучше использовать как стартовую точку, после которой спорный параметр проверяется отдельным инструментом.
SEO-анализ страницы
SEO-анализ страницы
Проверка помогает посмотреть основные on-page SEO-элементы и технические характеристики URL, которые доступны для анализа. Они дают представление о том, как страница оформлена для поисковой системы и пользователя, нет ли очевидного конфликта между содержанием документа и служебными указаниями.
CMS Detector / Определить CMS сайта
Определите CMS сайта онлайн по домену или URL. CMS Detector проверяет признаки движка, популярных платформ и веб-технологий и показывает результат за несколько секунд.
Проверка индексируемости
Проверьте, доступна ли страница для индексации Google: robots.txt, noindex, canonical, HTTP-статус и другие технические сигналы. Онлайн-проверка индексируемости URL.
Проверка индексации в Google
Проверьте, проиндексирован ли URL или страница сайта в Google. Способы через Search Console, site:, массовый чекер и причины отсутствия страниц в индексе.
PageSpeed / Core Web Vitals Checker
Core Web Vitals Checker и PageSpeed test онлайн: проверьте скорость сайта, LCP, INP, CLS и получите понятные рекомендации по оптимизации.
Проверка кодов ответа HTTP
HTTP Status Checker от Seo-Gen: проверьте код ответа URL, редиректы и ошибки 4xx/5xx онлайн. Подходит для одной страницы и массовой проверки URL.
Проверка редиректов
Redirect Checker онлайн: проверьте 301 и 302 редиректы, цепочки перенаправлений, HTTP-коды и конечный URL. Быстрая проверка редиректов без установки.
Проверка «битых» ссылок
Broken Link Checker от Seo-Gen: найдите битые и неработающие ссылки, 404 ошибки и проблемные URL на сайте. Онлайн-проверка внутренних и внешних ссылок.
Проверка robots.txt
Robots.txt Checker для проверки и анализа файла robots.txt онлайн. Найдите ошибки Allow, Disallow и User-agent, проверьте доступ URL для Googlebot и других поисковых роботов.
Проверка sitemap.xml
Sitemap Checker от Seo-Gen проверяет XML Sitemap онлайн: ошибки структуры, URL, sitemap index, lastmod, лимиты и доступность. Найдите проблемы до отправки карты сайта в Google.
Проверка meta robots
Meta robots Checker проверяет Meta Robots и X-Robots-Tag, находит noindex, nofollow и конфликты директив. Вставьте URL и проверьте настройки страницы.
Проверка canonical
Canonical Checker онлайн: проверьте rel=canonical, целевой URL, HTTP-статус и типовые ошибки канонизации страницы. Быстрая проверка canonical для SEO.
Проверка hreflang
Hreflang Checker от Seo-Gen: проверьте hreflang, x-default, canonical, языковые и региональные коды, обратные ссылки и ошибки URL онлайн.
Проверка индексации и доступности страницы
Страница может нормально открываться у пользователя и при этом иметь ограничения для поисковой системы. Причиной бывают meta robots, robots.txt, неправильный canonical, ошибочный HTTP-ответ или другие настройки. Поэтому проверка индексации начинается с понимания двух разных состояний: разрешено ли индексирование технически и находится ли URL в индексе Google.
Эти проверки дополняют друг друга. Индексируемый URL может ещё не присутствовать в Google, особенно если он опубликован недавно. И наоборот, страница, которая раньше индексировалась, после изменения настроек может получить запрет на дальнейшее индексирование.
Проверка индексируемости
Проверка индексируемости помогает определить, нет ли технических причин, препятствующих нормальной обработке URL поисковой системой. При диагностике учитываются настройки, которые могут ограничивать сканирование или индексирование страницы.
Такую проверку полезно запускать после публикации нового раздела, снятия тестовых ограничений и переноса сайта. Ошибки часто появляются именно после технических работ, когда временный noindex, закрытый каталог или неправильный canonical остаются на рабочей версии.
Что может запрещать индексацию?
На индексирование могут влиять разные сигналы. Среди них meta robots с директивой noindex, ограничения сканирования, ошибочный canonical на другой документ и серверный ответ, при котором поисковая система не получает нормальную страницу.
Проверять их лучше последовательно. Если URL возвращает ошибку 5xx, дальнейший анализ мета-тегов уже не объясняет основную причину. Если сервер отвечает 200, следующим шагом можно проверить meta robots, canonical и доступность страницы для поискового робота.
Проверка индексации в Google
Проверка индексации в Google отвечает на другой вопрос: присутствует ли конкретный URL в поисковом индексе. Это особенно полезно для недавно опубликованных страниц, обновлённых материалов, новых категорий и документов, которые раньше были закрыты от индексирования.
Отсутствие страницы в Google ещё не объясняет причину. После такого результата нужно проверить индексируемость, robots.txt, meta robots, canonical и HTTP-код. Если технических ограничений нет, причиной могут быть сроки обхода, качество страницы или решение поисковой системы не включать конкретный URL в индекс.
Meta robots Checker
Meta robots Checker проверяет инструкции для поисковых роботов, заданные на уровне страницы. Эти директивы могут определять возможность индексирования документа и обработку ссылок. Ошибочный meta robots особенно опасен на шаблонных страницах, потому что одна настройка способна затронуть сразу большой раздел.
Проверка нужна после переноса сайта с тестового домена, изменения шаблонов и работы с фильтрами. Если команда разработки временно закрывала страницы от индексации, перед релизом следует убедиться, что ограничения действительно сняты.
Noindex
Директива noindex сообщает поисковой системе, что страницу не следует включать в индекс. Она может быть уместна для служебных или технических документов, но на коммерческой категории, статье или странице услуги чаще указывает на ошибку настройки.
При неожиданном выпадении URL из поиска noindex проверяют одним из первых. После удаления директивы страницу нужно снова сделать доступной для обхода и дождаться повторной обработки поисковой системой.
Nofollow
Директива nofollow относится к обработке ссылок на странице. Она не означает автоматический запрет индексирования самого документа, поэтому её нельзя трактовать как полный аналог noindex.
При техническом аудите важно различать назначение этих директив. Если задача состоит в поиске причины отсутствия URL в индексе, основной интерес представляет noindex и другие ограничения индексирования, а nofollow оценивается в контексте ссылок.
Robots.txt Checker
Robots.txt Checker помогает проверить файл, который задаёт правила сканирования для поисковых роботов. Ошибка в robots.txt может закрыть важный каталог, раздел или технический ресурс, необходимый для корректной обработки сайта.
Особое внимание файлу уделяют после переноса, смены CMS и запуска нового проекта. В тестовой среде сайт часто закрывают от поисковых систем, а после публикации старое правило иногда остаётся без изменения.
Что важно проверить в robots.txt?
В первую очередь проверяют доступность файла и правила для нужных User-agent. Затем смотрят, не заблокированы ли коммерческие разделы, статьи, категории или другие страницы, которые должны участвовать в поиске.
Также полезно проверить ссылку на sitemap.xml, если она используется в файле. Robots.txt не следует воспринимать как универсальный способ удаления URL из индекса: его основная задача связана со сканированием.
Sitemap Checker
Sitemap Checker используется для проверки карты сайта. Sitemap.xml помогает поисковой системе находить URL, особенно на крупных проектах, где новые страницы могут находиться глубоко в структуре или появляться регулярно.
Карта сайта должна соответствовать реальной структуре проекта. Добавление URL в sitemap не гарантирует индексирование, но помогает поисковому роботу обнаруживать страницы и понимать набор адресов, которые владелец сайта считает актуальными.
Какие проблемы карты сайта важны для SEO?
В sitemap нежелательно оставлять удалённые страницы, постоянные редиректы, технические URL и документы, которые не должны индексироваться. Такие адреса создают противоречивые сигналы: карта предлагает страницу для обхода, а сам URL сообщает, что доступен другой документ или индексирование запрещено.
После изменения структуры рекомендуется проверить доступность sitemap и актуальность включённых адресов. Это особенно важно после массовой смены URL, миграции или удаления разделов.
Я начинаю техническую проверку страницы с того, может ли поисковая система нормально получить и индексировать нужный URL. Сначала смотрю HTTP-ответ, доступность для робота, meta robots и canonical. Если на этом уровне есть блокирующая ошибка, правки Title, H1 или текста не решат основную проблему. После этого проверяю редиректы, внутренние ссылки, hreflang, sitemap и производительность. Такой порядок помогает быстрее найти причину. Например, при ошибке 5xx нет смысла начинать с плотности ключевых слов, а при ошибочном noindex сначала нужно открыть страницу для индексирования и только потом оценивать её поисковую оптимизацию.
Как пользоваться инструментами аудита сайта?
Работа начинается с конкретной задачи. Если нужно узнать код ответа, выбирается HTTP Status Checker. Если страница отсутствует в поиске, логичнее начать с индексируемости и проверки индексации в Google. Такой подход сокращает количество лишних действий.
После первой проверки результат стоит сопоставить со связанными параметрами. Например, 301 требует проверки конечного URL, а отсутствие индексации – meta robots, canonical и robots.txt.
Укажите URL
Введите полный адрес страницы, которую нужно проверить. Желательно использовать фактический URL с правильным протоколом и доменом, чтобы результат относился именно к той версии, которую получают пользователи и поисковые системы.
Если проверяются разные версии адреса, запускайте их отдельно. HTTP, HTTPS, www и non-www могут отвечать по-разному, особенно после миграции или изменения серверной конфигурации.
Запустите нужную проверку
Выберите инструмент под текущую задачу. Необязательно сразу проверять все параметры, если проблема известна заранее. При подозрении на неправильный canonical нет смысла начинать со скорости загрузки.
Когда причина непонятна, можно начать с SEO-анализа страницы и постепенно переходить к профильным инструментам. Так проще выстроить диагностику от общего состояния к конкретной ошибке.
Изучите результат
Смотрите не только на значение параметра, но и на его смысл для текущей страницы. Код 301 может быть правильным для старого URL и ошибочным для действующей посадочной, которая должна открываться напрямую.
То же относится к noindex, canonical и hreflang. Техническая настройка оценивается в контексте назначения URL, структуры сайта и ожидаемого поведения поискового робота.
Исправьте проблему и выполните проверку повторно
После изменения сайта запустите ту же проверку ещё раз. Это помогает убедиться, что правка действительно попала на рабочую версию и сервер возвращает ожидаемый результат.
Повторная проверка особенно нужна для редиректов, robots.txt, canonical, hreflang и HTTP-кодов. Задача считается закрытой после проверки фактического результата, а не после сохранения настройки в CMS или конфигурации сервера.
Инструменты для аудита сайта Seo-Gen
Раздел рассчитан на ситуации, когда специалисту нужен конкретный ответ по конкретному URL. Например, страница открывается в браузере, но отсутствует в поиске. В этом случае логично проверить индексируемость, наличие URL в Google, meta robots, robots.txt и canonical. Если пользователь попадает не туда, куда должен, понадобятся HTTP Status Checker и Redirect Checker.
Инструменты для SEO-анализа полезны и после технических работ. Разработчик может проверить новый редирект, SEO-специалист – canonical и hreflang, а владелец сайта – скорость загрузки страницы или наличие битых ссылок. Результаты отдельных проверок проще сопоставлять между собой, потому что каждая отвечает на один понятный вопрос.
Что можно проверить без полного SEO-аудита?: Отдельная SEO-проверка подходит, когда известен проблемный URL или есть подозрение на конкретную ошибку. Можно проверить ответ сервера, доступность страницы для индексирования, наличие запрета noindex, правильность canonical, настройки hreflang, карту сайта, robots.txt, скорость загрузки или цепочку перенаправлений. Такой анализ URL особенно удобен перед публикацией и после изменений. Если разработчик поменял адрес страницы, достаточно проверить старый URL, конечный адрес и HTTP-код. Если изменялся шаблон мультиязычных страниц, полезно отдельно проверить canonical и языковые версии. Для крупного сайта эти точечные проверки дополняют регулярный технический аудит сайта.
Как выбрать нужную проверку?
Выбор зависит от симптома. Когда страница не появляется в поиске, сначала проверяют её техническую доступность и настройки индексирования. При неправильном переходе между адресами проверяют код ответа и маршрут редиректа. Если сайт стал медленнее после обновления, смотрят PageSpeed и Core Web Vitals.
Для быстрой ориентации можно использовать такую схему:
| Проблема | Что проверить |
|---|---|
| Страница не индексируется | Индексируемость, Google Index, robots.txt, meta robots, canonical |
| URL открывается неправильно | HTTP Status Checker, Redirect Checker |
| Пользователь получает 404 | HTTP-код, редирект, битые ссылки |
| Сайт работает медленно | PageSpeed, Core Web Vitals |
| Ошибки мультиязычности | Hreflang Checker, canonical |
| Неизвестен движок сайта | CMS Detector |
| Есть подозрение на битые ссылки | Broken Link Checker |
После первой проверки часто становится понятно, какой инструмент нужен следующим. Так диагностика идёт от причины к связанным техническим параметрам, а не превращается в просмотр десятков показателей без приоритета.
Ответы на ваши вопросы
Можно ли проверить сайт без полного SEO-аудита?
Да, если задача относится к конкретной странице или параметру. Можно отдельно проверить индексацию, HTTP-код, редирект, robots.txt, sitemap, canonical, hreflang, битые ссылки или Core Web Vitals.
Полный аудит нужен, когда причина проблемы неизвестна или ошибки затрагивают структуру сайта. Тогда отдельные проверки используются как часть более широкого анализа.
Чем проверка индексируемости отличается от проверки индексации в Google?
Индексируемость показывает, есть ли технические ограничения, которые могут мешать поисковой системе обрабатывать страницу. Проверка индексации отвечает на вопрос, находится ли конкретный URL в индексе Google.
Страница может быть технически доступна и при этом ещё не находиться в индексе. Поэтому эти два результата нужно рассматривать отдельно.
Как проверить, почему страница не индексируется?
Сначала нужно проверить HTTP-ответ, индексируемость, robots.txt, meta robots и canonical. Если эти параметры корректны, можно проверить наличие URL в Google и оценить другие причины отсутствия страницы в поиске.
Одна проверка редко объясняет все случаи. Причина может состоять из нескольких технических сигналов, особенно после переноса или изменения шаблона.
Как проверить код ответа страницы?
Для этого используется HTTP Status Checker. Он показывает статус, который сервер возвращает при обращении к конкретному URL, например 200, 301, 404 или ошибку группы 5xx.
После получения результата нужно оценить, соответствует ли код назначению страницы. Для действующей посадочной обычно ожидается успешный ответ, а для старого перенесённого URL может быть корректным постоянный редирект.
Как найти неправильный редирект?
Redirect Checker помогает увидеть перенаправление, промежуточные переходы и конечный URL. Затем нужно проверить, соответствует ли конечная страница исходному адресу по смыслу и возвращает ли она корректный HTTP-код.
Особое внимание стоит уделить циклам и длинным цепочкам. Внутренние ссылки желательно сразу вести на финальную версию страницы.
Для чего проверять hreflang?
Hreflang связывает языковые и региональные версии одной страницы. Проверка помогает найти неправильные адреса, отсутствующие обратные ссылки и ошибки языковых кодов.
Для мультиязычного сайта желательно проверять весь набор альтернатив одной страницы. Canonical при этом не должен противоречить выбранной структуре языковых версий.
Какие показатели входят в Core Web Vitals?
К основным Core Web Vitals относятся LCP, INP и CLS. Они описывают скорость отображения основного содержимого, отзывчивость интерфейса и визуальную стабильность страницы.
Плохой результат указывает направление диагностики, но сам по себе не называет точную причину. Для исправления нужно найти конкретный ресурс, скрипт или элемент макета, который влияет на метрику.
Можно ли определить CMS чужого сайта?
CMS Detector анализирует публично доступные технические признаки сайта и пытается определить используемую систему управления контентом. Для этого не требуется доступ к административной панели.
Некоторые проекты определить однозначно нельзя. Причиной может быть собственная CMS, изменённая структура стандартной платформы или скрытые технические признаки.
Подробнее: Инструменты для аудита сайта
Проверка HTTP-ответов, редиректов и ссылок
HTTP-код показывает, какой ответ сервер возвращает при обращении к URL. Для SEO это базовый технический параметр: поисковый робот должен понимать, существует ли страница, была ли она перенесена, удалена или временно недоступна.
Редиректы и ссылки проверяются вместе с HTTP-ответами, потому что проблемы часто связаны. Внутренняя ссылка может вести на адрес с 301, затем на второй редирект и только после этого на конечную страницу. Такая цепочка работает для пользователя, но её стоит сократить.
HTTP Status Checker
HTTP Status Checker показывает код ответа страницы. Он нужен для проверки старых и новых URL, страниц после миграции, удалённых документов и адресов, которые ведут себя иначе, чем ожидалось.
Код сам по себе ещё не определяет наличие SEO-ошибки. Ответ 301 может быть правильным после переноса, а 404 – нормальным для окончательно удалённого URL, если у него нет релевантной замены.
Код 200
Ответ 200 OK означает, что сервер успешно обработал запрос и возвращает содержимое страницы. Для обычного индексируемого документа это ожидаемый статус.
При этом код 200 не подтверждает корректность всей SEO-настройки. На странице всё ещё могут присутствовать noindex, ошибочный canonical или другие параметры, поэтому HTTP-проверка дополняется анализом документа.
Коды 301 и 302
Код 301 обычно применяют для постоянного перенаправления, когда старый адрес заменён новым. Код 302 используется для временного перенаправления, если исходный URL планируется вернуть.
При проверке важно видеть не только статус, но и целевой адрес. Ошибочный редирект может отправлять пользователя и поискового робота на нерелевантную страницу или создавать лишнюю цепочку переходов.
Коды 404 и 410
Код 404 сообщает, что запрашиваемая страница не найдена. Код 410 указывает на удалённый ресурс. Такие ответы следует проверять у URL, на которые продолжают вести внутренние ссылки, sitemap или внешние переходы.
Если у удалённой страницы есть близкая по смыслу замена, может потребоваться корректный редирект. Перенаправлять все удалённые URL на главную страницу без учёта содержания не стоит.
Ошибки 5xx
Коды группы 5xx указывают на серверную проблему. Если важная страница регулярно отвечает таким статусом, поисковый робот не может стабильно получать её содержимое.
Единичный кратковременный сбой отличается от постоянной ошибки. При повторяющемся 5xx нужно проверить сервер, приложение, прокси, базу данных и журнал ошибок, а затем повторно протестировать URL.
Redirect Checker
Redirect Checker показывает, происходит ли перенаправление и куда в итоге попадает запрос. Это полезно при переносе сайта, смене структуры URL, переходе на HTTPS и объединении дублей.
После массовых изменений редиректы нужно проверять выборочно и системно. Ошибка в одном шаблонном правиле способна перенаправить сотни страниц на неправильные адреса.
Цепочки редиректов
Цепочка возникает, когда один URL перенаправляет на второй, второй – на третий, а пользователь только после нескольких переходов получает конечную страницу. Такие маршруты часто остаются после нескольких последовательных миграций.
Для внутренней перелинковки лучше сразу использовать конечный адрес. Если цепочка сформировалась из старых редиректов, её стоит сократить там, где это возможно без нарушения логики переноса.
Конечный URL
При проверке редиректа нужно смотреть конечный адрес и его HTTP-ответ. Сам факт перенаправления не гарантирует правильный результат: конечная страница может возвращать 404, второй редирект или нерелевантный документ.
Особенно внимательно проверяют страницы с органическим трафиком и внешними ссылками. Для них ошибка в конечном URL может повлиять сразу на пользователей, индексацию и передачу накопленных сигналов.
HTTP → HTTPS и www → non-www
Перенаправления между HTTP и HTTPS, а также между вариантами домена с www и без него помогают привести адреса к выбранной основной версии. Конкретный вариант домена зависит от настроек проекта.
При проверке нужно убедиться, что переход происходит последовательно, без циклов и лишних промежуточных адресов. Внутренние ссылки желательно сразу вести на финальную HTTPS-версию URL.
Broken Link Checker
Broken Link Checker помогает находить ссылки, которые ведут на отсутствующие или технически недоступные страницы. Битая ссылка ухудшает навигацию и оставляет поискового робота на URL, где нет ожидаемого документа.
Проверка полезна после удаления товаров, статей, категорий, смены структуры и миграции. Даже если старые страницы корректно удалены, внутренние ссылки на них нужно обновить или убрать.
Почему битые ссылки нужно исправлять?
Битые внутренние ссылки нарушают путь между связанными страницами и создают лишние обращения к ошибочным URL. На большом сайте такие ссылки накапливаются после регулярных изменений контента и структуры.
Исправление зависит от ситуации. Ссылку можно заменить актуальным адресом, удалить, если переход больше не нужен, или настроить редирект со старого URL на релевантную новую страницу.
Проверка canonical и hreflang
Canonical и hreflang решают разные задачи, но особенно часто пересекаются на мультиязычных сайтах. Canonical указывает предпочтительный URL среди похожих документов, а hreflang связывает языковые или региональные версии одной страницы.
Ошибки в этих элементах могут создавать противоречия. Например, украинская версия страницы указывает canonical на русскую, одновременно заявляя отдельный hreflang. Такие случаи нужно проверять на уровне конкретных URL.
Canonical Checker
Canonical Checker помогает увидеть канонический адрес страницы и проверить, соответствует ли он ожидаемой логике сайта. Для уникального индексируемого документа часто используется self-canonical, но возможны и другие схемы.
Canonical рассматривается поисковой системой как сигнал. Поэтому он должен согласовываться с редиректами, sitemap, внутренними ссылками и реальной структурой URL.
Self-canonical
Self-canonical означает, что страница указывает канонический адрес на саму себя. Такой вариант часто используют для основных индексируемых URL, чтобы явно обозначить предпочтительную версию документа.
После изменения домена, протокола или структуры стоит проверить, обновился ли canonical. Старый адрес в теге может остаться после миграции и отправлять поисковой системе неверный сигнал.
Canonical на другой URL
Canonical на другой адрес может быть корректным для дубля или альтернативной технической версии страницы. Проблема возникает, когда уникальная посадочная случайно ссылается на другой документ.
При такой ошибке поисковая система может выбрать другой URL в качестве канонического. Поэтому целевой адрес необходимо проверять вместе с содержанием страницы и её ролью в структуре сайта.
Canonical и дубли страниц
Дубли могут возникать из-за GET-параметров, фильтров, сортировок, вариантов URL и особенностей CMS. Canonical помогает обозначить основную версию, но не заменяет нормальную архитектуру сайта.
Если дублей много, нужно анализировать причины их появления. Иногда правильнее изменить генерацию ссылок, закрыть технические комбинации или настроить редиректы, а canonical оставить дополнительным сигналом.
Hreflang Checker
Hreflang Checker нужен для мультиязычных и мультирегиональных сайтов. Он помогает проверить, какие альтернативные версии указаны для страницы и корректно ли они связаны между собой.
Для Seo-Gen эта проверка особенно полезна на проектах с русской, украинской и английской версиями. Каждая страница должна ссылаться на соответствующие языковые альтернативы, а адреса – отвечать ожидаемым статусом.
Языковые версии страницы
Hreflang связывает страницы с одинаковым назначением, но разным языком или регионом. Украинская версия услуги должна вести на её украинский URL, русская – на русский, английская – на английский.
При проверке следует смотреть не только код языка, но и сам адрес. Ошибка часто возникает, когда шаблон подставляет URL другой страницы или старую структуру после миграции.
Взаимные hreflang-ссылки
Связь между языковыми версиями должна быть взаимной. Если украинская страница указывает русскую как альтернативу, русская версия должна корректно ссылаться обратно.
После добавления нового языка такие связи иногда остаются неполными. Поэтому лучше проверять сразу весь набор языковых версий одной страницы, а не только один тег в исходном коде.
x-default
Значение x-default используют для страницы, которая подходит пользователям, когда ни одна конкретная языковая или региональная версия не выбрана. Его применение зависит от архитектуры проекта.
Проверять x-default нужно вместе с остальными hreflang. Адрес должен существовать, быть логичным для пользователя и не создавать конфликтов с canonical или редиректами.
PageSpeed и Core Web Vitals Checker
PageSpeed и Core Web Vitals Checker помогают оценить производительность страницы и показатели пользовательского опыта, связанные со скоростью отображения, отзывчивостью и визуальной стабильностью. Проверка полезна после редизайна, подключения новых скриптов, изменения изображений и обновления фронтенда.
Низкая производительность требует технического разбора причины. Проблема может находиться в изображениях, JavaScript, серверном ответе, CSS, шрифтах или сторонних интеграциях. Одного числового результата недостаточно: нужно понимать, какая часть страницы создаёт задержку.
Что показывает проверка скорости?
Проверка скорости помогает увидеть показатели загрузки и технические метрики страницы. Их используют, чтобы сравнить состояние URL до и после оптимизации, найти слабые места и проверить результат работы разработчика.
При анализе стоит учитывать тип страницы. Тяжёлая карточка товара, лендинг с большим количеством интерактивных элементов и простая информационная статья имеют разную структуру, поэтому причины замедления у них тоже отличаются.
Основные Core Web Vitals
К основным Core Web Vitals относятся LCP, INP и CLS. Эти показатели описывают разные части пользовательского опыта и оцениваются отдельно, поэтому улучшение одной метрики не гарантирует хорошего результата по двум другим.
При технической оптимизации сначала находят конкретный элемент или процесс, который ухудшает показатель. После исправления страницу тестируют повторно, желательно в тех же условиях.
LCP
Largest Contentful Paint показывает, насколько быстро отображается основной крупный элемент в видимой области страницы. Часто им оказывается главный баннер, крупное изображение или большой текстовый блок.
На LCP могут влиять скорость ответа сервера, загрузка изображения, CSS, шрифты и порядок загрузки ресурсов. Поэтому исправление начинается с определения конкретного LCP-элемента.
INP
Interaction to Next Paint характеризует отзывчивость страницы при взаимодействии пользователя с интерфейсом. Высокое значение может быть связано с тяжёлыми JavaScript-задачами или обработчиками событий.
Проверка особенно актуальна для сайтов с фильтрами, калькуляторами, выпадающими меню, формами и другими интерактивными компонентами. После оптимизации скриптов показатель нужно измерить повторно.
CLS
Cumulative Layout Shift показывает визуальную стабильность страницы. Если элементы заметно смещаются во время загрузки, пользователь может случайно нажать не на ту кнопку или потерять место чтения.
Причиной часто становятся изображения без заданных размеров, поздняя загрузка баннеров, шрифтов или динамических блоков. Исправление требует работы с конкретными элементами макета.
Почему показатели нужно смотреть отдельно для мобильных устройств?
Мобильное устройство обычно работает в других условиях: меньше вычислительных ресурсов, нестабильнее соединение и меньше экран. Поэтому страница, которая быстро открывается на рабочем компьютере, может заметно тормозить на смартфоне.
Проверка мобильной версии особенно важна для проектов, где большая часть поискового трафика приходит с телефонов. Оптимизацию следует проводить по фактическим проблемам страницы, а затем повторно измерять показатели.
CMS Detector – как определить CMS сайта
CMS Detector помогает определить систему управления контентом по доступным техническим признакам сайта. Такая проверка пригодится перед аудитом, переносом проекта, оценкой разработки или подготовкой технического задания.
Знание CMS помогает быстрее понять возможные ограничения и типовую структуру проекта. WordPress, OpenCart, Shopify, собственная CMS и другие платформы по-разному работают с URL, шаблонами, расширениями и служебными файлами. При этом окончательные выводы всё равно нужно делать после технического анализа конкретного сайта.
Как определяется CMS?
Определение CMS строится на публично доступных признаках, которые сайт передаёт при обычном обращении. Это могут быть характерные элементы HTML, структура ресурсов, технические пути и другие данные, доступные без входа в административную часть.
Не каждый сайт удаётся определить однозначно. Разработчик может изменить стандартную структуру, скрыть характерные признаки или использовать собственную платформу. В таком случае корректнее показать отсутствие уверенного результата, чем указывать CMS без достаточных оснований.
Какие SEO-ошибки исправлять в первую очередь?
Приоритет зависит от влияния проблемы на доступность и индексирование страницы. Если URL возвращает серверную ошибку или случайно закрыт noindex, работа с мета-тегами и текстом не устранит основную причину.
Сначала исправляют проблемы, которые мешают поисковой системе получить нужную страницу. Затем переходят к ошибкам структуры и техническим сигналам, после чего занимаются производительностью и дополнительной on-page оптимизацией.
Критические проблемы
К критическим относятся ситуации, когда важная страница недоступна, отдаёт постоянную серверную ошибку, закрыта от индексирования по ошибке или перенаправляет пользователя на неправильный документ.
Такие проблемы желательно проверять сразу после релиза и технических изменений. Если ошибка затрагивает шаблон, нужно определить масштаб и проверить несколько URL одного типа.
Ошибки высокой важности
К этой группе можно отнести неправильный canonical, битые внутренние ссылки, некорректные hreflang и проблемы sitemap, если они затрагивают важные индексируемые страницы.
Исправление начинается с проверки шаблона и источника данных. Одинаковая ошибка на десятках страниц обычно требует системной правки, а не ручного изменения каждого URL.
Оптимизационные проблемы
После устранения блокирующих ошибок можно работать со скоростью, Core Web Vitals, мета-тегами и другими on-page параметрами. Их влияние зависит от состояния страницы и конкурентности запроса.
Приоритет лучше определять по данным сайта. Страница с трафиком и плохой производительностью обычно важнее технического URL, который почти не участвует в поиске.
Когда достаточно отдельного инструмента, а когда нужен полный аудит сайта?
Отдельный инструмент подходит, если проблема локальная и понятная. Например, нужно проверить один редирект, найти HTTP-код страницы, узнать canonical или убедиться, что новый URL появился в Google. Такой формат экономит время и даёт конкретный технический ответ.
Полный SEO-аудит нужен при падении органического трафика, миграции, смене CMS, масштабном редизайне или большом количестве связанных ошибок. В этих случаях нужно анализировать архитектуру, индексирование, внутренние ссылки, контент, технические параметры и внешние факторы вместе.
Кому пригодятся инструменты Seo-Gen?
Инструменты рассчитаны на специалистов, которым регулярно приходится проверять отдельные URL и технические параметры сайта. Набор задач одинаково знаком SEO-специалистам, разработчикам, владельцам проектов и агентствам, хотя каждый использует результаты по-своему.
Главное преимущество точечных проверок – возможность быстро перейти от симптома к конкретному параметру. При этом сложные проблемы всё равно требуют анализа причин и связей между страницами.
SEO-специалистам
SEO-специалист может быстро проверить индексируемость, meta robots, canonical, hreflang, редиректы и HTTP-ответы без ручного просмотра каждого технического элемента.
Такие проверки особенно удобны при приёмке задач разработчика и после публикации изменений. Результат можно сопоставить с требованиями ТЗ и сразу увидеть, соответствует ли рабочая страница ожидаемому состоянию.
Разработчикам
Разработчику инструменты полезны после изменений маршрутизации, серверной конфигурации, шаблонов и мультиязычности. Они помогают проверить результат с точки зрения поискового робота и реального HTTP-ответа.
После релиза можно протестировать основные URL, убедиться в корректности редиректов, robots.txt, sitemap, canonical и hreflang, а затем исправить найденные расхождения.
Владельцам сайтов и маркетологам
Владельцу сайта не обязательно вручную разбирать исходный код, чтобы выполнить первичную проверку страницы. Можно узнать HTTP-статус, проверить индексирование, скорость или наличие технического запрета.
Результат помогает точнее поставить задачу разработчику или SEO-специалисту. Вместо формулировки «страница пропала из Google» появляется конкретная информация о параметрах URL.
Агентствам
Агентства регулярно работают с проектами на разных CMS и технических стеках. Быстрые проверки удобны при первичном анализе, приёмке доработок и контроле сайтов после релиза.
Отдельные инструменты также помогают перепроверять спорные URL без запуска большого краулера. Для масштабного аудита они дополняют профессиональные системы сканирования, а не заменяют анализ всей структуры проекта.
Что показывает SEO-анализ страницы?
Если в результате видно спорный параметр, его стоит проверить отдельно. Например, неправильный canonical требует Canonical Checker, проблема с ответом сервера – HTTP Status Checker, а возможный запрет индексирования – проверки meta robots и индексируемости.
Title, Description и H1
Title, Description и H1 помогают поисковой системе понять тему страницы, а пользователю – оценить её содержание ещё до перехода из результатов поиска. При проверке нужно смотреть наличие элементов, их соответствие странице и отсутствие очевидных противоречий между заголовком документа и основным содержанием.
Дублирование одинаковых мета-тегов на большом количестве страниц затрудняет нормальную оптимизацию, особенно у категорий, услуг и геостраниц. Слишком длинный или бессодержательный Title тоже требует проверки. При этом длина сама по себе не должна оцениваться отдельно от поискового интента и смысла страницы.
Технические SEO-параметры
Технические SEO-параметры показывают, получает ли поисковый робот ожидаемую версию документа и нет ли служебных указаний, которые противоречат задаче страницы. Особенно внимательно проверяют URL, которые недавно создавались, переносились, закрывались на время разработки или меняли адрес.
Если обнаружена потенциальная SEO-ошибка, лучше перейти к профильной проверке. Индексируемость, meta robots, canonical, HTTP-код и hreflang связаны между собой, но отвечают за разные процессы. Раздельная диагностика помогает установить причину, а не ограничиваться общим сообщением о проблеме.
Ссылки и структура страницы
Внутренняя ссылка передаёт пользователю и поисковому роботу путь к другому документу сайта. Ошибочные адреса, ссылки на удалённые страницы и ненужные цепочки редиректов ухудшают навигацию и усложняют сканирование. Поэтому ссылки стоит проверять после переноса, изменения структуры URL и удаления разделов.
Внешние ссылки тоже требуют контроля, если они ведут на недоступные ресурсы. При проверке важен конечный HTTP-статус страницы, а не только наличие href в исходном коде. Для поиска таких проблем используется отдельный Broken Link Checker.
Когда использовать SEO-анализ страницы?
SEO-анализ страницы удобно проводить перед запуском новой посадочной, после внесения SEO-правок и перед передачей задачи на проверку. Он также полезен после обновления CMS, изменения шаблонов мета-тегов, переноса страницы на новый URL или изменения структуры заголовков.
Повторная проверка нужна после исправлений. Если разработчик изменил canonical, meta robots или редирект, результат следует проверить уже на рабочем сайте. Для технического SEO важен фактический ответ страницы, который получает робот после публикации, а не настройка, указанная в задаче разработчику.
Инструменты для аудита сайта Seo-Gen помогают отдельно проверять те параметры, которые чаще всего приходится разбирать при технической оптимизации: индексируемость, наличие URL в Google, HTTP-статусы, редиректы, битые ссылки, robots.txt, sitemap, meta robots, canonical, hreflang и Core Web Vitals.
Начните с проблемы, которую нужно проверить, выберите соответствующий инструмент и после исправления запустите проверку повторно. Если причина затрагивает несколько разделов или органический трафик снижается без очевидного объяснения, переходите от отдельных тестов к полноценному SEO-аудиту сайта.
Отвечаем в течение рабочего дня. Без рассылок и звонков «просто напомнить».
Посмотрит сайт сам, а не передаст менеджеру.