# SEO-требования к шаблону сайта и микроразметка **Для человека:** технические требования, при которых страницы сайта попадают в поиск и не мешают друг другу: индексация, канонические адреса, заголовки, скорость, картинки, соцсети и микроразметка Schema.org. Дай файл нейронке на фазе 8 из SAYT.md: «Собери шаблон сайта и страниц так, чтобы выполнялся каждый пункт 06-seo-trebovaniya-i-razmetka.md; в конце пройди чек-лист из раздела 8». Про сам процесс выкладки на домен — файл `07-vykat-indeksaciya.md`. --- ## 1. Индексация: разговор с краулером - **Никогда не блокируй CSS/JS в robots.txt.** Google должен полностью отрендерить страницу, чтобы оценить скорость и мобильность. Заблокируешь — он видит «пустую» страницу. - **Disallow ≠ удаление из выдачи.** Чтобы убрать страницу из поиска, нужен noindex на самой странице, открытой для сканирования. **Грабля, которая стоит недель.** Флаг блокировки хранится как свойство страницы (`isRoboted`). Если сначала закрыть страницу в robots.txt, а потом добавить noindex, Google уже не заходит на неё и **никогда не увидит** твой noindex. Сначала открой доступ, потом ставь noindex. **Sitemap.xml:** только канонические URL, без параметров и UTM; не включать закрытые и noindex-страницы; `lastmod` менять только при реальном изменении (Google сверяет и перестаёт верить фиктивным датам). Каждая новая страница должна попадать в карту автоматически при публикации, а не руками. **Глубина клика: чем дальше от главной, тем «старее» страница.** Краулер обходит сайт по ссылкам. Чем больше переходов от главной до статьи, тем реже он к ней заходит и тем меньше веса она получает — со стороны это выглядит как «старый, забытый материал». Отсюда жёсткое требование к листингу: **пагинация обычными ссылками-цифрами** (`/blog/page/2`). Кнопка «Показать ещё» и бесконечный скролл подгружают статьи скриптом — в HTML ссылок нет, и старые материалы остаются **без единой ссылки на себя**. Целься так, чтобы до любой статьи было не больше 3 кликов от главной. ## 2. Canonical и дубли - Все версии домена (http/https, www/non-www) → 301 на одну каноническую. - Canonical на страницах с параметрами (фильтры, сортировки, UTM) → на чистый URL. - Никаких «петель»: A→B и B→A одновременно. - Мусорные параметрические URL (`?from=`, `utm_*`) не должны индексироваться. **Почему это важно.** Google сверяет дубли по контрольной сумме контента (`ContentChecksum96`) и по пересекающимся цепочкам слов (`shingleInfo`). Механическая синонимизация от дублей не спасает — цепочки из 3–5 слов остаются. Много почти-дублей → сайтовый штраф «замусоренности» (`clutterScore`), который топит весь домен. ## 3. Структура URL - Читаемые, из слов, через дефис (не подчёркивания, не `%20`), только латиница нижнего регистра. - Иерархия папок = зеркало структуры сайта; хлебные крошки с разметкой BreadcrumbList. - URL стабилен: продумываем структуру **до** публикации, меняем только через 301. **Не ставь год в URL вечнозелёного контента.** URL вида `/luchshie-noutbuki-2026/` «вшивает» год в дату страницы навсегда (`syntacticDate`). Через год свежесть проседает, а обновление конфликтует со старым годом. Год — только в метаданных, не в URL. ## 4. Заголовки: Title и H1 Малоизвестный факт: твой `` не финальный. У Google есть система (Goldmine), которая собирает **пул кандидатов** на заголовок в выдаче: твой title, твой H1, тексты ссылок на страницу и даже сгенерированный самим Google. Победителя выбирают в том числе по кликам. **Вывод.** Если `<title>`, `<h1>`, URL и первый абзац говорят о разном, ты сам создаёшь себе конкурентов на свой заголовок. Если по чужому кандидату кликают лучше, Google покажет его. - `<title>` и `<h1>` — про одно и то же (можно разными словами). Ключ — в начале, в URL и в первых 50–100 словах. - **Ровно один `<h1>` на странице.** Иерархия H1→H2→H3 без пропусков: Google режет её на «чанки» для сниппетов и AI-ответов. - Заголовки — только для заголовков, не для красоты (Google измеряет даже визуальный размер шрифта термина). - Длина title считается **в пикселях** (~600 на десктопе), не в символах. Без повтора слов в title. ## 5. Скорость как триггер поведения (Core Web Vitals) Скорость — не прямой фактор ранжирования. Но медленный сайт порождает badClick: человек кликнул, страница тормозит — вернулся в выдачу, и система понизила страницу. Пороги «хорошо»: | Метрика | Что это | Порог | |---|---|---| | LCP | Появление главного блока | < 2,5 с | | INP | Отклик на действие | < 200 мс | | CLS | Скачки вёрстки | < 0,1 | Первое, что чинить для LCP, — время ответа сервера (TTFB): CDN, кэш, лёгкий шаблон. Мобильные метрики весят больше десктопных. И **первый экран** должен отвечать на запрос сразу: заголовок, короткий ответ, картинка по делу — без стены текста. ## 6. Микроразметка Schema.org ### Что она делает, а что нет Разметка **описывает поисковику то, что уже видит пользователь на странице**. Отсюда три правила: - **Schema — не фактор ранжирования.** Добавление разметки само по себе не поднимает позиции. - **Разметка не гарантирует расширенный сниппет.** Показывать его или нет решает поисковик, и он регулярно сокращает типы, которые показывает. Свежий пример — FAQPage: Google почти полностью убрал его показ для обычных сайтов. - **Размечать можно только то, что реально есть на странице, и только подходящими типами.** Разметка невидимого контента или чужого типа — нарушение рекомендаций, ловит предупреждения в панелях и в лучшем случае игнорируется. Практический вывод: **не гнаться за количеством типов.** Пять-шесть типов, которые соответствуют странице и валидны по свойствам, полезнее двадцати «на всякий случай». ### Базовый набор - **Organization** — на главной (можно и на «Контактах»): название/бренд, логотип, сайт, соцсети, контакты. Практически обязательна. - **WebSite** — только на главной: описание сайта, URL, при желании SearchAction (поиск по сайту). - **Article / BlogPosting / NewsArticle** — основная разметка статьи. Article — универсально, BlogPosting — для блога, NewsArticle — только новостник. Поля: headline, description, image, author, publisher, datePublished, **dateModified** (машиночитаемый, не только бейдж на странице), mainEntityOfPage. - **BreadcrumbList** — хлебные крошки. - **Person** — автор статьи (отдельная страница автора или вложенный объект в Article). Поля: name, image, url, sameAs. Если авторов несколько — обязательно, очень желательно и для одного. ### По необходимости - **FAQPage** — только если на странице реально есть видимый блок вопросов-ответов. На расширенный сниппет не рассчитывай: Google почти прекратил показ FAQ-сниппетов обычным сайтам. Сам блок FAQ имеет смысл, когда у читателя правда остаются вопросы, — по содержанию, а не ради разметки. - **ImageObject** — основная картинка статьи (автор, лицензия, URL); обычно внутри Article. - **WebPage** — описание страницы: name, description, breadcrumb, primaryImageOfPage, lastReviewed. - **CollectionPage** — для категории, рубрики, архива (лучше, чем Article). - **ItemList** — списки статей, категории, подборки, топы («10 лучших…»). ### Ситуативные - **VideoObject** — если в статье есть видео. - **HowTo** — если статья-инструкция («Как установить…»). Не для обычных информационных статей. - **Product** — только если статья реально про товар. - **Review** — если есть полноценный отзыв или экспертная оценка. - **SoftwareApplication** — для сайтов про ИИ, SaaS, онлайн-инструменты: operatingSystem, applicationCategory, offers. - **Service** — если описывается услуга. - **Event** — если страница про мероприятие. - **Course** — если есть обучающие курсы. - **QAPage** — не путать с FAQ: только если пользователи задают вопрос, а другие отвечают (формат Stack Overflow). ### Минимум по типам страниц - Главная — Organization + WebSite. - Статья — Article/BlogPosting + BreadcrumbList + Person (автор). - Листинг — ItemList или CollectionPage. - Карточки, обзоры, видео — Product / Review / VideoObject / HowTo по смыслу. Нейронке в задании перечисли **только те типы, которые соответствуют реальным страницам проекта**, не весь список подряд. Потом отдельной задачей проверь валидацию (Rich Results Test и валидатор Яндекс.Вебмастера) и убедись, что размеченное содержимое действительно видно на странице. Лишний тип — не «запас», а источник предупреждений. ## 7. Картинки, соцсети и лента Три вещи, которые обычно забывают в шаблоне, а потом дописывают руками по всем страницам сразу. Дешевле заложить с первого дня. ### Open Graph — как выглядит ссылка при пересылке Ссылку на страницу кидают в Телеграм, ВК и рабочие чаты. Без Open Graph там появляется голый URL, который никто не открывает; с ним — карточка с заголовком, описанием и картинкой. Это не фактор ранжирования, это переходы и упоминания. - `og:title`, `og:description` — можно короче и человечнее, чем title/description для выдачи. - `og:image` — **абсолютный** URL обложки, 1200×630, до пары сотен килобайт. Относительный путь не подхватится. - `og:url` (канонический адрес), `og:type=article`, `twitter:card=summary_large_image`. ### Имена файлов и alt - **Осмысленные имена файлов** латиницей через дефис: `kak-vybrat-solnechnye-paneli.webp`, а не `IMG_2841.jpg` и не `1.png`. Имя файла — один из немногих текстов, по которым поиск понимает картинку; это бесплатный трафик из поиска по изображениям. - **Alt уникальный и по делу:** описывает, что на изображении. Не копирует H1 и подзаголовки и не повторяется от картинки к картинке — одинаковые alt по всему сайту поиск читает как шаблонный мусор. - Подпись под изображением — видимый текст, его читают и люди, и поиск. Ставим там, где картинка что-то объясняет. ### RSS — если публикуешь регулярно Лента `/rss.xml` с последними статьями, объявленная в `<head>` через `<link rel="alternate" type="application/rss+xml">`. Даёт вторую точку обнаружения новых URL помимо sitemap, подхватывается агрегаторами и читалками. Если статьи выходят регулярно — десять минут работы один раз. ## 8. Чек-лист требований к шаблону - [ ] robots.txt не блокирует CSS/JS; ключевые страницы не под noindex - [ ] Один канонический домен, self-canonical на статьях, canonical на чистый URL для параметров - [ ] URL латиницей, через дефис, стабильные, без года для вечнозелёного - [ ] Один H1, иерархия заголовков без пропусков; title ≈ h1 - [ ] CWV в зелёной зоне; лёгкий шаблон; первый экран отвечает сразу - [ ] Schema — только типы, соответствующие странице, и только по видимому содержимому; валидна в Rich Results Test - [ ] Мобильная вёрстка проверена; нет навязчивых pop-up при переходе из поиска - [ ] Юр-страницы (152-ФЗ): политика, согласие у форм, cookie, маркировка рекламы (образцы — `09-yur-obraztsy.md`) - [ ] CTA-баннеры внутри статьи — обычным блоком, не заголовком (не рвут иерархию H1→H2→H3) - [ ] Пагинация ссылками-цифрами (не «показать ещё», не бесконечный скролл); до любой статьи ≤3 клика от главной - [ ] Open Graph заполнен: og:title, og:description, og:image (абсолютный URL, 1200×630), og:url, og:type - [ ] Имена файлов картинок осмысленные; alt уникальный, не копирует H1 и не повторяется - [ ] Новые страницы попадают в sitemap.xml автоматически; при регулярном постинге — RSS-лента, объявленная в `<head>` ## Источники Все факты о работе поиска — из публично раскрытых источников: - **Утечка внутренней документации Google** (Content Warehouse API, май 2024). Разбор Майка Кинга (iPullRank): ipullrank.com/google-algo-leak; SparkToro: sparktoro.com. - **Антимонопольное дело США против Google** (US v. Google LLC, № 1:20-cv-03010) — показания Панду Наяка о роли кликов (NavBoost). - **Core Web Vitals** — официальная документация Google: web.dev/articles/vitals. - **Микроразметка** — schema.org и Google Search Central: developers.google.com/search/docs. Имена внутренних сигналов Google (`isRoboted`, `ContentChecksum96`, `clutterScore`, `syntacticDate` и др.) приведены как доказательная база.