- Robots.txt и sitemap.xml
- Ссылки должны быть ссылками
- Генерируйте критически важный контент на стороне сервера — используйте SSR
- Каждая страница должна иметь свой адрес (URL). И желательно с ЧПУ
- Каждая страница должна иметь уникальные метатеги
- Индексируемый тег noindex/nofollow
- Используйте API для сохранения истории состояния страниц в браузере
- Проверьте правильно ли настроена страница 404 not found
В последние годы все популярнее разработка веб-приложений на JavaScript, различных фреймворках на его основе и прочих SPA (single page application). Это такие сайты, где в браузере пользователя загружается одна единственная страница, а содержимое страницы генерируется динамически. Контент меняется в зависимости от действий посетителя без необходимости перезагрузки страницы.
Подобный подход в разработке интернет ресурсов применяют даже при создании сайтов на популярных CMS, таких как WordPress, Битрикс и других.
Разработчики оставляют знакомые и привычные всем бекенд — админки, архитектуру, а фронтед, часть, с которой непосредственно взаимодействует пользователь, делают на каком нибудь популярном фреймворке — Vue JS, Next JS или другом. Таких фреймворков сейчас множество, что также говорит о том как это модно и молодежно.
Но, очень редко ТЗ на разработку подобных сайтов содержит даже минимально необходимые настройки для дальнейшего SEO-продвижения. Причины чаще всего одна. Как разработчики, так и заказчики даже не подозревают насколько сильно, если заранее не предусмотреть многие нюансы, такие проекты отличаются от обычных сайтов с точки зрения поисковиков. А ранжировать в выдаче такие сайты поисковые системы будут на общем основании. И плевать они хотели на то, насколько они инновационные и современные.
Google — руководство в чуть более приемлемом состоянии, однако панель в Google Search Console тоже в бэте
Более того, заказчики довольно часто даже не подозревают что разработчик применили подобный метод разработки для фронтенда. Потом они очень сильно удивляются, когда приходят к SEO-специалисту или в агентство а им выкатывают с десяток технических заданий на доработку. Часто такие доработки влекут за собой значительные дополнительные траты. А еще сложности для разработчиков, которым иногда необходимо вносить большие изменения в изначальную архитектуру проекта.
Эта инструкция предназначена для того, чтобы помочь владельцам и разработчикам избежать таких проблем. SEO-специалистам она поможет систематизировать подход к анализу таких проектов и перестать бояться брать их в работу. Да, многие их боятся. А ведь такие сайты зачастую очень удобны для пользователя и при правильном подходе могут даже выиграть в продвижении у обычных сайтов за счет поведенческих факторов.
Robots.txt и sitemap.xml
Главные поисковые файлы с точки зрения поисковых систем. Обязательно предусмотрите их наличие при разработке.
Robots.txt содержит рекомендации для поисковых систем о том, какие страницы, директивы, разделы, а также возможные варианты адресов (URL) стоит индексировать, а какие обходить стороной. Он помогает поисковому роботу не тратить краулинговый бюджет на обход маловажных страниц и адресов, избежать дублей, не индексировать служебные страницы и адреса. В общем, скрыть из поиска все то, что не относится к контенту, который необходим пользователю в поиске. А еще повысить общую релевантность сайта.
А еще он содержит ссылку на карту сайта sitemap.xml.
Можно сделать его редактируемым из административной панели сайта, а можно просто загрузить в корневую папку сайта. Но он обязательно должен быть доступен по адресу мойсайт.рф/robots.txt
Sitemap.xml — это своеобразное оглавление для сайта.
Как в книге мы ищем оглавление на второй, либо предпоследней странице сайта, так поисковая система по умолчанию ищет этот файл по адресу мойсайт.рф/sitemap.xml.
Как оглавление в книге этот файл содержит систематизированную информацию о структуре сайта, его главах. Часто в нем также есть указания для поисковых систем о степени важности тех или иных страниц и разделов, ссылки на изображения, когда та или иная страница была в последний раз отредактирована.
Карта сайта должна содержать все страницы, которые должны быть проиндексированы, не должна содержать служебных страниц и директив, и в ней никогда не должно оказаться страниц, которые не существуют или удалены.
Карту сайта, если на проекте часто создаются новые страницы, стоит сделать автоматически генерируемой. Хотя, есть множество инструментов для ручного создания карты сайта.
Ссылки должны быть ссылками
Поисковые системы индексируют веб-ресурсы переходя по ссылкам. Если они не видят ссылки, они не смогут перейти на следующую страницу сайта, а значит не смогут построить правильную структуру проекта и построить релевантную выдачу. Поэтому ссылки очень важны.
Когда дело доходит до ссылок и SEO-продвижения, необходимо по возможности использовать стандартные ссылки с атрибутом href (<a href=»…»>). Такие ссылки легко обнаруживаются и отслеживаются поисковыми роботами.
Однако если ссылки, сгенерированные JavaScript, присутствуют, поисковые системы все равно могут их найти и проиндексировать. Такие ссылки можно использовать в определенных ситуациях, например, при создании (с осторожностью) динамических навигационных меню или (без ограничений) при обработке взаимодействия с пользователем (открытие форм, табов, спойлеров и т. д.).
Используйте стандартные HTML-ссылки для навигации и внутренних ссылок.
Хороший пример:
<a href="/products">Products</a>
Плохой пример:
<a href="#" onclick="loadProducts()">Products</a>
Генерируйте критически важный контент на стороне сервера — используйте SSR
Поисковый робот видит страницу сайта не совсем так, как ее видит пользователь. В целом, увидеть страницу глазами робота можно очень просто. Нажатием на странице в браузере правой кнопки мыши и вызвать контекстное меню, где выбрать «Посмотреть исходный код страницы» или нажав в большинстве браузеров комбинацию клавиш «Ctrl+U».
Проверьте этим способом страницы своего веб-приложения на JavaScript. Нашли в нем весь контент, который должен увидеть пользователь — очень хорошо, вам сильно повезло, можете пропустить эту главу. Увидели только непонятные наборы символов — очень плохо. Большинство разработчиков и владельцев таких проектов встретят как раз второй вариант.
Дело в том, что разработчики таких сайтов стараются максимально перенести генерацию контента на странице непосредственно в браузер пользователя. Главная причина — экономия ресурсов сервера. Однако заигравшись, они совершенно не думают о поиске. Что не удивительно, они и не должны, они же не SEO-специалисты. Поэтому следует им подсказать.
Запомните главное — если чего то нет в исходном коде страницы — этого не существует и для поискового робота. А значит он не увидит весь тот замечательный продающий SEO-текст, за который владелец сайта заплатил деньги копирайтеру или долго разрабатывал сам.
Пример плохого исходного кода:
Пример исходного кода SPA здорового человека:
И для этого в большинстве JavaScript-фреймворках существует решение — SSR, server side rendering. По-простому — генерация контента на стороне сервера. Да, это будет съедать какую то часть ресурсов хостинга/сервера, но зато вы можете быть уверены в том, что поисковый робот увидит все то, что видит пользователь в своем браузере. Ну или ту, его часть, которую вы хотите, чтобы робот увидел и проиндексировал.
В идеале, генерироваться на стороне сервера должно все, что начинается с открывающего тега <head> и до закрывающего тега </body>, причем генерироваться он должен именно как HTML-код.
Внутри тега <head> находятся критически важные для поискового продвижения элементы title, description, часто микроразметка, в большинстве случаев ссылка на таблицу стилей, которая помогает структурировать контент, в том числе для поискового робота.
Внутри тега <body> весь основной контент — текст, изображения, таблицы и т. д.
Только так вы можете быть уверены в том, что страница правильно и полностью будет проиндексирована поисковыми системами.
Каждая страница должна иметь свой адрес (URL). И желательно с ЧПУ
Если по логике работы приложения при определенных действиях пользователя на странице меняется ее контекст, постарайтесь создать для этой сущности свой адрес, URL. И пусть страница в браузере не перезагружается, но URL в строке должен измениться, также он должен измениться и для поисковой системы, а также стать доступным (со всеми логическими изменениями) по прямой ссылке.
И не слушайте разработчиков, которые говорят, что это невозможно! Им просто лень все переделывать. Еще со времен появления стека технологий под названием AJAX, разработчики успешно решали такую задачу.
Только в случае реализации этого подхода поисковые системы смогут правильно построить для себя, а значит и для потенциального клиента в поиске, релевантную структуру сайта. А еще это помогает увеличить количество страниц в поиске и оптимизировать каждую конкретную страницу под отдельно взятый набор поисковых фраз.
- Для основных страниц постарайтесь генерировать ЧПУ (человеко-понятный URL). Старайтесь использовать мойсайт.рф/phone-cases вместо мойсайт.рф/product-id1. Это положительно влияет на кликабельность в поиске и упрощает навигацию.
- По-максимуму избавляйтесь от динамических параметров в URL, например мойсайт.рф/product?id=1&color=red, если только при такой логике не настроена смена контента на странице, включая title и description. Даже в таком случае, старайтесь продумать присвоение таким страницам ЧПУ.
- Если избавиться от динамических параметров в URL не представляется возможным, а контент на странице значительно не меняется, предусмотрите индексируемый тег canonical. Каноническая ссылка должна указывать на основную страницу в структуре без параметров.
- Используйте пагинацию при динамической загрузке дополнительного контента на странице. Если даже в проекте используется кнопка вроде «Загрузить еще» или дополнительный контент подгружается автоматически (например плавная загрузка следующей статьи или товара), URL должен меняться соответственно. При этом в случае с пагинацией обязателен тег canonical на каждой следующей «странице» (https://example.com/products?page=2, https://example.com/products?page=3), указывающий на страницу без пагинации.
Каждая страница должна иметь уникальные метатеги
Настройте на проекте генерацию в зависимости от параметров, либо возможность редактирования (в идеале и то и другое) уникальных метатегов для каждой страницы, которая должна быть проиндексирована поисковой системой.
Метатеги title и description важны для поисковой системы и во многом влияют на то, как страница будет выглядеть на странице поисковой выдачи. Формируют поисковый сниппет. Они должны быть уникальны для каждой страницы сайта. Если это не так, на ошибку указывает даже Яндекс Вебмастер. Робот может пометить такие страницы как дубли, а наличие дублей плохо влияют на поисковое продвижение.
Продумайте все это заранее.
Индексируемый тег noindex/nofollow
Хотя robots.txt и указывает поисковому роботу на то, какие директивы сайта не должны быть проиндексированы поисковым роботом, он имеет рекомендательный характер.
Чтобы наверняка запретить критически важные страницы, которые 100% не должны быть проиндексированы (например, с целью безопасности), необходимо наличие тега noindex/nofollow непосредственно на странице. И этот тег, обязательно должен быть виден поисковой системе, то есть находиться в исходном коде, а значит генерироваться на сервере.
В идеале этот тег должен отдаваться на таких страницах ответом на запрос сервера с помощью X-Robots-Tag.
Используйте API для сохранения истории состояния страниц в браузере
В SEO-продвижении сегодня поведенческие факторы очень важны. Поэтому, если при возвращении назад пользователь не получит того результата, который он ожидает увидеть, в проекте критически увеличится количество отказов.
Кроме того, поисковый робот, следующий за пользователем, так же не увидит привычного поведения страниц. Это также может серьезно повлиять на ранжирование сайта в выдаче.
К счастью в современной веб-разработке нашли выход для JavaScript проектов. Правда, далеко не все разработчики о нем знают и еще меньше применяют на практике.
Это метод сохранения истории состояния страниц в браузере с помощью pushState() и replaceState(). Настоятельно рекомендую внедрять его на все JavaScript проекты. Это поможет избавиться от большого количества ошибок при сканировании сайта поисковым роботом.
Проверьте правильно ли настроена страница 404 not found
Правильно настроенная страница 404 это важный элемент технической SEO-оптимизации, который напрямую и не очень влияет на эффективность поискового продвижения в Google и Яндекс.
Самая популярная ошибка — неверный ответ сервера на запрос несуществующей страницы. Проверьте, точно ли ответ на такой запрос возвращает код 404. Это можно сделать с помощью стандартной функции интерфейса Яндекс Вебмастер — Инструменты -> Проверка ответа сервера. Несуществующий URL должен отдавать 404 код ответа сервера. Не 301, не 200, не 403, а именно 404.
Кроме того, страница должна быть оформлена в общем дизайне, иметь элементы навигации. Пользователь, который случайно попал на такую страницу, не должен подумать что он оказался на другом ресурсе. А страница должна помочь ему перейти в другие разделы сайта, а не закрыть вкладку браузера. Таким образом страница ошибки 404 page not found помогает избежать ухудшения поведенческих факторов, на которые в большей степени обращает внимание Яндекс.
Главное правило: все SEO-критичные элементы должны быть заложены в архитектуру проекта на этапе разработки, а не добавляться постфактум.
