Техническое SEO корпоративного сайта — чек-лист 2026 года

Индексация, зеркала и редиректы, Core Web Vitals, мобильная версия, микроразметка и метатеги. Чек-лист технического SEO для проверки корпоративного сайта перед запуском и затем раз в квартал, с пояснениями, где смотреть и что ломается чаще всего.

Техническое SEO корпоративного сайта — чек-лист 2026 года — обложка статьи
Обсудим ваш проект?

Оставьте телефон, перезвоним и ответим на вопросы по теме статьи.

Имя
Телефон*
Почта
Коротко
  • 1Технический аудит начинается с индексации. Проверяют robots.txt, sitemap.xml, коды ответа сервера, canonical и отчёты в Яндекс Вебмастере и Google Search Console.
  • 2У сайта должно быть одно главное зеркало, и все варианты адреса, с www и без, по http и https, ведут на него 301-редиректом.
  • 3Хорошая оценка Core Web Vitals означает LCP не больше 2,5 с, INP не больше 200 мс и CLS не больше 0,1.
  • 4Минимальный набор микроразметки корпоративного сайта включает Organization и BreadcrumbList, а на соответствующих страницах Article, FAQPage, Product или Service.

Технический SEO-аудит корпоративного сайта проверяет шесть вещей. Это индексация, зеркала с редиректами, скорость по Core Web Vitals, мобильная версия, микроразметка с метатегами и дубли страниц. Ошибка в любом из блоков обесценивает работу с текстами и ссылками, потому что робот либо не находит страницы, либо понимает их не так, как вы рассчитывали.

По этому чек-листу мы в Вебтехе проверяем сайты перед запуском и когда принимаем чужой проект на поддержку. Большую часть пунктов можно пройти самостоятельно с Яндекс Вебмастером, Google Search Console и бесплатными сервисами проверки скорости. Где без разработчика не обойтись, мы это отмечаем.

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

Начинать стоит с простого вопроса. Могут ли роботы найти и прочитать все нужные страницы, и не тратят ли они время на мусор? Если сайт не подключён к Вебмастеру и Search Console, сделайте это первым делом, иначе остальные проверки придётся проводить вслепую. Минимальный набор проверок такой:

  1. Сайт добавлен в Яндекс Вебмастер и Google Search Console, права подтверждены, регион указан.
  2. robots.txt не закрывает рабочие разделы и файлы стилей и скриптов, но закрывает корзину, личный кабинет, результаты внутреннего поиска и служебные страницы, а параметры сортировки и UTM-метки для Яндекса убраны директивой Clean-param.
  3. sitemap.xml собирается автоматически, содержит только канонические страницы с ответом 200 и указан в robots.txt.
  4. На рабочем сайте нет метатега noindex, оставшегося от тестовой версии.
  5. Рабочие страницы отдают код 200, удалённые 404 или 410 с полезной страницей ошибки, перемещённые 301 на новый адрес.
  6. Тестовые и старые версии сайта закрыты паролем, а не одним robots.txt.

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

С тестовыми версиями есть ещё одна тонкость. Файл robots.txt запрещает обход, но не индексацию, и если на тестовый адрес где-то стоит ссылка, страница может попасть в выдачу без описания. Пароль на уровне сервера надёжнее.

Зеркала, редиректы и дубли страниц

Для поисковика адреса с www и без, по http и https, со слешем на конце и без него считаются разными страницами. Если все варианты открываются, у сайта появляются дубли, а внешние ссылки и поведенческие сигналы размазываются между ними.

Выберите главное зеркало, чаще всего это https без www, и настройте на него 301-редирект со всех остальных вариантов. Директиву Host в robots.txt Яндекс больше не поддерживает, зеркало теперь определяется только редиректами. Заодно приведите адреса к одному формату. Со слешем на конце или без, неважно, лишь бы одинаково по всему сайту и в нижнем регистре. И проверьте, что главная не открывается как /index.php или /index.html.

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

С дублями внутри сайта работают через canonical. Его ставят на страницах сортировки и фильтров, на пагинации и на адресах с UTM-метками, чтобы поисковик понимал, какую версию считать основной. На корпоративном сайте дублей обычно меньше, чем в интернет-магазине, но они всё равно появляются, например когда одна услуга доступна из двух разделов меню по разным адресам. Такое легко пропустить. При переезде на новую CMS и смене дизайна этот блок проверяют особенно внимательно, подробнее об этом в статье про редизайн без потери трафика.

Скорость загрузки и Core Web Vitals

Core Web Vitals — три метрики Google, которые показывают, насколько быстро и стабильно страница работает у реальных посетителей. Для Яндекса скорость тоже важна, хотя и косвенно. Медленные страницы хуже удерживают людей и реже обходятся роботом.

МетрикаЧто измеряетХорошее значениеЧастые причины проблем
LCP (Largest Contentful Paint)Время отрисовки самого крупного элемента первого экрана≤ 2,5 сТяжёлые изображения и видео в первом экране, медленный сервер, блокирующие шрифты
INP (Interaction to Next Paint)Задержку реакции на клики и ввод≤ 200 мсТяжёлый JavaScript, сторонние виджеты, чаты, счётчики
CLS (Cumulative Layout Shift)Смещение элементов при загрузке≤ 0,1Изображения и баннеры без заданных размеров, подгружаемые блоки, шрифты

Оценку ставят по полевым данным, то есть по тому, что получают реальные пользователи на своих устройствах, и посмотреть их можно в отчёте Core Web Vitals в Search Console. Лабораторные тесты вроде Lighthouse удобны для поиска причин, но итоговая оценка строится не по ним. Бывает, что тест на мощном рабочем компьютере даёт зелёные цифры, а у посетителей со старыми смартфонами и мобильным интернетом та же страница открывается секунд пять. Верить стоит второму.

Причины проблем на корпоративных сайтах довольно однообразны. LCP портят тяжёлое видео или огромная фотография на первом экране, медленный хостинг и шрифты, которые блокируют отрисовку. INP страдает от JavaScript, особенно стороннего, когда на сайте одновременно висят онлайн-чат, виджет обратного звонка, два счётчика и пиксель соцсети. CLS появляется, если картинки и баннеры выводятся без заданных размеров и текст прыгает при загрузке.

Что с этим делать, зависит от платформы и бюджета. Изображения переводят в WebP или AVIF, нарезают под размеры экранов и включают ленивую загрузку всего, что ниже первого экрана. Сторонние скрипты грузят отложенно, а каждый виджет проверяют на влияние на INP и честно решают, нужен ли он вообще. На сервере включают кеширование и сжатие, переходят на HTTP/2 или HTTP/3, статику отдают через CDN. Часть этого настраивается за день, а часть, например замена тяжёлой готовой темы на WordPress, тянет за собой переделку вёрстки.

Мобильная версия и безопасность

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

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

С безопасностью всё приземлённо. HTTPS на всех страницах, действующий сертификат и никакого смешанного контента, когда отдельные картинки или скрипты грузятся по http. Следите за обновлениями CMS и модулей. Взломанный сайт с вредоносным кодом поисковики помечают в выдаче и понижают, и восстанавливаться после этого гораздо дольше и дороже, чем вовремя поставить обновление.

Микроразметка и метатеги

Микроразметка schema.org подсказывает роботу, какая организация стоит за сайтом и какой контент на странице. Для корпоративного сайта минимальный набор выглядит так:

  • Organization или LocalBusiness с названием и логотипом, адресами офисов, телефонами, ссылками на официальные профили.
  • BreadcrumbList на всех внутренних страницах.
  • Article или BlogPosting для статей блога с автором и датами.
  • FAQPage для блоков вопросов и ответов.
  • Product или Service для каталога продукции и страниц услуг.

С FAQPage есть нюанс. С 2023 года Google показывает FAQ-сниппеты в основном для авторитетных государственных и медицинских сайтов, так что коммерческий сайт расширенного сниппета скорее всего не увидит. Разметку всё равно стоит оставить, она помогает роботам разобрать структуру страницы, а нейросетевым ответам найти готовые пары вопросов и ответов. На web-tex.pro статьи блога размечены как BlogPosting и FAQPage, а для языковых моделей в корне лежит файл llms.txt. Зачем он нужен, мы писали в материале про GEO-оптимизацию. Проверяйте разметку валидатором Яндекса и инструментом проверки расширенных результатов Google.

Метатеги удобнее проверять краулером по всему сайту сразу, а не постранично. У каждой страницы должен быть свой title длиной до 60–70 знаков с основным запросом ближе к началу и description на 140–160 знаков. На странице один H1, под ним логичная иерархия H2 и H3, у содержательных изображений заполнен alt. Разметка Open Graph отвечает за превью, когда ссылку на сайт отправляют в мессенджер или соцсеть. Без неё менеджер пересылает клиенту ссылку на коммерческое предложение, а в чате вместо заголовка и картинки появляется случайный кусок меню. Мелочь, но неприятная.

Регулярный контроль после запуска

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

  1. Сразу после запуска установите Яндекс Метрику и настройте цели на отправку форм, звонки, клики по мессенджерам и скачивание прайса.
  2. Раз в неделю открывайте Вебмастер и Search Console и смотрите новые ошибки, исключённые страницы и проблемы безопасности.
  3. Раз в месяц прогоняйте сайт краулером на битые ссылки и лишние редиректы, дубли title и description.
  4. Раз в квартал проходите весь чек-лист заново, потому что после доработок и обновлений ошибки появляются незаметно.

Пункт с Метрикой здесь не случайно. Без целей невозможно понять, что техническая работа дала бизнесу, и разговор о SEO сводится к позициям вместо заявок.

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

В разработке сайтов мы закладываем эти пункты с самого начала, потому что исправлять после запуска дольше и дороже. До релиза настраиваются зеркала и редиректы, файлы sitemap.xml и robots.txt, разметка с метатегами и цели аналитики, а Core Web Vitals проверяются ещё на этапе вёрстки. Мы работаем на 1С-Битрикс и WordPress и знаем слабые места обеих платформ. Если сайт уже работает, чек-лист можно встроить в регулярную техническую поддержку вместе с мониторингом и обновлениями. Обсудить аудит вашего сайта можно через бриф.

Услуги по теме

Частые вопросы

Полный аудит делают перед запуском сайта, после редизайна или переезда на новую CMS и в штатном режиме примерно раз в квартал. Отчёты Яндекс Вебмастера и Google Search Console полезно открывать раз в неделю, в них быстро видны новые ошибки индексации и проблемы со скоростью.

Чаще всего виноваты закрытые разделы в robots.txt, метатег noindex, оставшийся от тестовой версии, неверный canonical, ошибки сервера или слишком медленные ответы. Начните с Яндекс Вебмастера. Проверка ответа сервера, статистика обхода и список исключённых страниц обычно показывают причину.

INP (Interaction to Next Paint) показывает, как быстро страница реагирует на действия пользователя в течение всего визита. В марте 2024 года Google заменил им метрику FID, которая учитывала только первое взаимодействие. Хорошее значение INP не больше 200 мс.

Нужна. Даже без расширенного сниппета разметка помогает роботам понять тип страницы, организацию, автора и структуру. Это пригодится и в Яндексе, и в нейросетевых ответах, которые опираются на поисковый индекс.