Уроки SEO, которые мы вынесли из исправления собственного сайта

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

Сайт в одном абзаце

mythex.ai — это одностраничное приложение, которое мы предварительно рендерим на этапе сборки: скрипт обходит каждый маршрут, записывает для него статический HTML-файл и вставляет в него заголовок страницы, описание и структурированные данные (блок JSON-LD, который сообщает поисковикам, что это за страница; см. что такое структурированные данные). Большая часть дальнейшего относится к этому шагу предварительного рендеринга, потому что именно этот HTML действительно читает поисковый робот.

1. Каждая страница заявляла, что она — страница FAQ

Симптом. В нашем HTML-шаблоне в структурированных данных был общий для всего сайта блок FAQPage с URL, указывающим на /faq. Затем предварительный рендеринг добавлял к каждой странице её собственный FAQPage. Так что каждая страница сайта отдавала два блока, а наша политика конфиденциальности сообщала Google, что это страница FAQ.

Почему это важно. Google ожидает не более одного FAQPage на странице. Второй блок, который указывает на что-то другое, — это тот случай, когда разметка страницы обесценивается, а не просто игнорируется.

Исправление. Общий блок удалён. Разметка FAQ каждой страницы теперь формируется из одного места, включая сам /faq, который собирает её из полного списка вопросов. На страницах без FAQ теперь не объявляется никакой разметки, и это честный ответ. Кроме того, предварительный рендеринг завершается ошибкой сборки, если какая-либо страница снова получит больше одного FAQPage. Правило, которое живёт только в чьей-то памяти, рано или поздно нарушают; правило, которое обеспечивает сборка, — нет.

2. Google использовал для нас не ту картинку

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

Почему так вышло. Мы никогда не сообщали Google, какое изображение представляет страницу, и он выбрал то, что нашёл.

Исправление. Две стороны одной проблемы:

• Укажите, какое изображение принадлежит странице. На главной странице теперь есть узел WebPage со свойством primaryImageOfPage, которое указывает на карточку для публикации, а в структурированных данных каждой предварительно отрендеренной страницы есть собственное изображение (картинка для публикации этой страницы или изображение по умолчанию).
• Скройте декорации. Фоновые изображения теперь запрещены в robots.txt и отдаются с заголовком noindex, noimageindex, поэтому они не попадают в поиск по картинкам и миниатюры.

3. Поисковики знали о нас только логотип

В разметке Organization у нас были название, логотип и несколько ссылок на соцсети — только брендинг и ничего больше. Поисковые системы строят панель знаний о компании на основе реестровых фактов, поэтому мы добавили те, что есть в нашей торговой лицензии: юридическое название, дату основания, основателя и юридический адрес. Номер телефона мы намеренно не указали.

4. Шаблонные страницы отвечали не на тот вопрос

Симптом. Search Console показывала, что три шаблонные страницы получают показы, но не клики. Одна ранжировалась по запросу «content strategist portfolio» и его вариантам, другая — по «best italian restaurant website design», третья — по группе запросов вокруг «agile board»; почти половина этих запросов содержала слово «free». Позиции колебались от середины двадцатых до пятидесятых.

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

Исправление. У каждой из трёх страниц теперь есть раздел, написанный для поискового запроса, а не для продукта, заголовок и описание со словами, которые люди вводят в поиск, и FAQ, которые стоят той разметки, что они уже выдавали.

В том же коммите исправили и менее заметную проблему. Блок «похожие шаблоны» брал первые четыре шаблона в категории, поэтому все шаблоны портфолио ссылались на одни и те же четыре портфолио, а остальные в категории вообще не имели внутренних ссылок. Мы заменили его кольцом, упорядоченным по подкатегориям: теперь каждая страница шаблона получает ровно четыре входящие и четыре исходящие ссылки. Кроме того, ссылки теперь выводятся в предварительно отрендеренном HTML. Раньше они появлялись только после выполнения JavaScript, а это может не произойти никогда.

5. Сообщать Bing о новых страницах сразу после деплоя

Google игнорирует IndexNow, протокол, с помощью которого сообщают поисковикам об изменении URL. Bing, Yandex и Seznam его используют, а индекс Bing читает поиск ChatGPT. Конструктор приложений с AI, который не могут найти AI-ассистенты, — это особый вид провала.

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

За работу отвечают две детали:

• Сделайте снимок до деплоя. Базовая версия должна быть зафиксирована до того, как новая сборка выйдет в эксплуатацию. Потом «живая» карта сайта уже новая, и каждая разница получается пустой.
• Пока только новые страницы. В нашей карте сайта нет дат lastmod, поэтому скрипт сообщает о новых страницах, но не о переписанных. Если бы каждый URL получал дату сборки, весь сайт помечался бы как изменённый при каждом деплое, то есть именно тот спам, которого мы избегали.

Скрипт работает только при деплоях в продакшен и никогда не роняет сборку: к моменту его запуска сайт уже опубликован, а пинг поисковику не стоит красной сборки.

6. Наш собственный edge отвечал «не найдено»

При запуске страниц /ai (подробнее о них в статье лендинг для каждого вида бизнеса) на стейджинге все они показывали «Not found», хотя статический хостинг отдавал их нормально.

Сервис перед нашими маркетинговыми хостами пропускал только разрешённый список путей, а всё остальное получало жёсткую 404. Раздел /ai был новым и в список не попал. Мы добавили /ai и /ai/* и тест, который проверяет, что они проходят. Ошибка небольшая, но именно такая, из-за которой новый раздел становится невидимым для поисковых роботов, и никто этого не замечает.

Что мы из этого вынесли

• Читайте HTML, который читает поисковый робот. Большая часть этих проблем была невидима в браузере и очевидна в предварительно отрендеренном файле.
• Превращайте правила SEO в проверки сборки. «Один FAQPage на страницу» теперь обеспечивается, а не держится на памяти.
• Сообщайте поисковикам, что вы имеете в виду. Если не сказать, какое изображение или какие факты вас представляют, они будут угадывать.
• Search Console показывает, какой вопрос задавали люди. Показы без кликов обычно означают, что страница отвечала на другой вопрос.
• Отправляйте разницу, а не всё. Пинг только того, что изменилось, помогает не упираться в ограничения частоты запросов.

Если вы делаете то же самое для сайта, который построили сами, наши руководства SEO для сайтов, созданных с помощью AI и настройка Google Search Console описывают основы.