Яндекс теперь сканирует сайты AJAX, загружая оригинальные URL и выполняя на них JavaScript. Два устаревших механизма официально выведены из эксплуатации, и сайты, которые все еще используют их, работают против краулера.
Что больше не поддерживается
meta name="fragment" content="!"— игнорируется. Робот индексирует оригинальную страницу вместо этого. Сопутствующая схема?_escaped_fragment_=версий HTML поэтому является балластом.- Hash-bang (
#!) URL — Яндекс рекомендует полностью отказаться от этого подхода.
Миграция
- Измените ссылки в карте сайта (sitemap), чтобы они не содержали
#. - Замените ссылками с фрагментами в интерфейсе на реальные пути, используя History API.
Почему это важнее, чем кажется
Яндекс четко формулирует правило: при поиске ссылок на AJAX-страницах бот учитывает только URL в href атрибуте, а фрагменты не перенаправляются. Их собственный пример стоит усвоить — навигация из <a href="#/clothes"> и <a href="#/shoes"> дает вообще ни одной доступной для обнаружения страницы. Та же навигация, записанная как /clothes и /shoes с роутингом History API, полностью доступна для сканирования.
В этом разница между одностраничным приложением, которое индексируется, и тем, которое не индексируется, и это решение о маршрутизации, принятое на ранней стадии разработки кем-то, кто не думает о поиске.
Что проверить в существующем приложении
- Являются ли внутренние ссылки настоящими
hrefзначениями с реальными путями, или это обработчики кликов на элементах без тега anchor? Второй случай невидим для краулера. - Возвращает ли каждый маршрут полный документ при запросе напрямую или только при достижении через оболочку приложения?
- Содержит ли карта сайта те же URL, которые фактически обслуживает роутер?
Направление движения
Отказ от схемы с фрагментами означает, что больше нет специального пути для JavaScript-приложений. Они индексируются как обычные сайты, что означает, что они должны вести себя как обычные сайты: один URL на представление, доступный напрямую, связанный якорями.
Как мы это применяем
The href-only rule is the fact worth handing to any front-end team before they choose a router. We have audited applications whose entire catalogue was unreachable because navigation was built on click handlers and fragments — the site worked perfectly for people and had one indexable page. Fixing it is a routing change, which is cheap early and expensive after launch.
Связанные услуги