Техническое SEO как чек-лист: что я проверяю на своих витринах

# Техническое SEO как чек-лист: что я проверяю на своих витринах

Недавно разбирал техническую «коробку» у пары своих витрин — портфолио и лендинги услуг. Не «аудит ради отчёта», а проход по чек-листу: что видит бот, что видит браузер, где сайт врёт сам себе. Ниже — обобщённо: что проверял, что нашёл, что поправил. Без доменов и без обещаний «+N% трафика».

1. Отдача контента ботам

Сначала смотрю HTML, который реально приходит в ответе. Текст, title, h1, description должны быть в разметке, а не только после гидрации в браузере. Пустой CSR-shell для робота — это страница без смысла, даже если человеку всё красиво рисуется.

Что находил: оболочка без текста. Что правил: отдавать ключевой контент уже в первом HTML.

Почему тут SSR на Next, а не обычный SPA на React

Пункт про «текст уже в HTML» — не вкус, а механика. Обычный SPA на React часто отдаёт почти пустой документ и ждёт, пока в браузере подтянется JS и нарисуется страница. Человеку после гидрации всё ок. Боту и превью-краулеру — нет: в первом ответе нет title/h1/текста, на которые вы рассчитываете.

SSR (и близкий к нему HTML из рендера на сервере) в Next отдаёт уже собранную разметку в первом ответе. Бот читает то, что вы положили в HTML. Клиентский React после этого может «оживить» интерфейс — но смысл страницы не зависит от того, выполнится ли скрипт у робота.

На практике для витрин и лендингов это значит: — меньше риска пустого CSR-shell в выдаче и в превью соцсетей; — проще держать уникальные title/description/h1 в реальном HTML, а не «когда-нибудь после hydrate»; — честный 404 и canonical тоже живут на серверном ответе, а не только в клиентском роутере.

SPA на React уместен для закрытых кабинетов и сильного интерактива после входа. Для публичных money-страниц, которые должны нормально открываться боту, я выбираю SSR (Next) именно из‑за первого HTML, а не «потому что модно».

2. Title, description, canonical

На ключевых страницах — свои title и meta description, плюс честный canonical. Дубли «одна и та же страница под разными адресами» без указания главной версии — классика.

Что находил: одинаковые title на разных разделах, canonical «на всякий случай» мимо. Что правил: уникальные мета и один канонический URL на страницу.

3. Один h1 и без служебных заглушек

Один h1 на страницу. В HTML не должно торчать служебных английских stubs вроде «Untitled» или внутренних кодовых ярлыков.

Что находил: два h1 или заголовок из шаблона. Что правил: один осмысленный h1, заглушки убрал.

4. Честный 404

Несуществующий адрес должен отдавать настоящий 404, а не soft-404 с кодом 200 и «страница не найдена» в теле. На самой 404 — noindex, чтобы ошибка не жила в индексе как контент.

Что находил: красивая «не найдено» с 200. Что правил: статус 404 + noindex.

5. Редиректы без хоровода

Цепочка должна быть короткой и предсказуемой: http → https; www → apex (или наоборот) через 301; trailing slash — без лишних прыжков туда-сюда. Отдельно смотрю, не ломается ли SSL на зеркале www.

Что находил: редирект в три шага и битый сертификат на одном из зеркал. Что правил: один 301 на канон, SSL на обоих вариантах хоста.

6. robots.txt и sitemap

Служебное закрыть. В sitemap — не тащить тонкие tech-страницы и дубли. Для Яндекса, если уместно, Host указывает на предпочтительный хост.

Что находил: в карте сайта служебные URL и зеркала. Что правил: sitemap только под индексируемое; robots — без лишнего «Allow всему».

7. Сжатие: gzip и brotli

Отдельно проверяю brotli. Запрос с Accept-Encoding: br должен получать Content-Encoding: br, а не только gzip «по старой привычке». Brotli обычно даёт меньший HTML/CSS/JS на тех же файлах — меньше вес ответа без смены контента.

Что находил: br в заголовке клиента, а в ответе только gzip или вообще без сжатия на HTML. Что правил: включил brotli (и оставил gzip как запасной путь).

8. Кэш HTML

no-store на всех HTML «на всякий случай» убивает CDN и повторные визиты. Наоборот, год s-maxage без purge после деплоя — посетитель долго видит старую вёрстку.

Что находил: либо жёсткий no-store, либо слишком длинный shared cache. Что правил: разумный max-age/s-maxage и способ инвалидировать после выкладки.

9. JSON-LD

Где уместно — Organization / WebSite / Article / Case. Не ради галочки, а чтобы сущности на сайте были явными для поисковика.

Что находил: пусто или устаревшая схема. Что правил: актуальный JSON-LD под тип страницы.

10. Тонкий контент vs карточки

Каталог карточек без текста — не то же самое, что страница услуги. Смотрю, есть ли на money-страницах нормальный текст и понятный CTA на услугу или контакт.

Что находил: красивые плитки почти без смысла для бота. Что правил: усилил текст и один явный призыв.

11. Дубли путей

Блог на поддомене и тот же блог по пути /blog/, кейсы с чужим canonical — поисковик сам выбирает, какую версию любить. Лучше выбрать одну и держать её.

Что находил: две «правильные» версии одной статьи. Что правил: один канон, редирект или noindex на зеркало.

12. Мелочи безопасности заголовков

HSTS, X-Content-Type-Options: nosniff. По желанию — убрать версию nginx из Server, чтобы не светить лишнее.

Что находил: без HSTS, Server с версией. Что правил: заголовки включил, версию убрал.

---

Итог такой: техническое SEO на своих витринах — это не магия и не «сеошник раз в год». Это чек-лист, который можно пройти за вечер и закрыть дыры, из‑за которых бот видит не то, что вы думаете. Brotli в этом списке не «вишенка», а такой же обязательный пункт, как canonical и честный 404: если клиент просит br, а вы отдаёте сырой HTML, вы просто дарите лишние килобайты на каждом запросе.

Если полезно — могу разобрать любой пункт отдельно: brotli на nginx/CDN, soft-404 или как не сломать кэш после деплоя.

#seo #техническоеSEO #webdev #brotli #разработка