SEO в 2020-е годы

Страница, которую видит пользователь, и документ, который получает поисковая система, — не одно и то же.

Пользователь открывает URL и видит готовую страницу: заголовок, текст, изображения, цены, кнопки, отзывы. Всё это появляется мгновенно, как будто страница просто существовала где-то на сервере и её оставалось только показать.

Поисковая система проходит через совсем другой процесс. Сначала нужно обнаружить URL — узнать, что он вообще существует. Затем получить его содержимое — не обязательно с первого раза и не обязательно в том же виде, в каком его получит браузер пользователя. Затем, если это необходимо, выполнить JavaScript — это отдельный этап обработки, который требует дополнительных ресурсов и не гарантирует получения того же результата, который видит пользователь. Извлечь текст и ссылки из результата. Определить, какую версию страницы считать канонической, если таких версий несколько. Решить, стоит ли вообще включать документ в индекс — и это решение может быть отрицательным даже для полностью корректной страницы. И только после всего этого, сопоставив документ с другими документами и с запросами пользователей, у поисковой системы появляется основание для того, чтобы вообще думать о позиции в выдаче.

Именно здесь начинается современное SEO. Не с позиции. С вопроса, доживёт ли документ до момента, когда позиция вообще станет иметь смысл.

Сайт, который выглядел исправным

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

Поисковая система видела этот сайт иначе.

Часть страниц она обнаруживала — но не индексировала, без явной ошибки, а просто не включая их в индекс, причём причина такого решения не всегда очевидна владельцу сайта. На некоторых URL содержимое, полученное после выполнения JavaScript, отличалось от того, что видел пользователь в браузере: часть блоков подгружалась по клику или при прокрутке, и поисковый робот не получал их в ходе обработки страницы. Xml-карта сайта (sitemap. xml) сообщала поисковику один набор страниц — актуальный, свежий, аккуратно сгенерированный. Внутренняя перелинковка сайта вела к другому набору. А часть технических сигналов на одних и тех же URL прямо противоречила друг другу: canonical указывал на одну версию, а hreflang — на другую структуру URL.

Ни один из этих фактов сам по себе не был катастрофой. И нельзя сказать, что сайт «плохо оптимизировали» — в привычном смысле, будто где-то забыли прописать тег или неправильно расставили ключевые слова. Проблема была глубже: сайт и поисковая система по-разному понимали, что именно является страницей. У сайта было одно представление о собственной структуре. У поисковой системы — другое. И работа с каждым из них по отдельности ничего бы не исправила, потому что несовпадение возникало именно на стыке.

SEO начинается раньше, чем принято думать

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

Долгое время это условие выполнялось как бы само собой. Сайт в основном представлял собой набор HTML-документов, каждый со своим URL. Сервер отдавал готовый документ, а поисковому роботу в большинстве случаев было достаточно получить его и разобрать разметку. Расхождение между «что видит пользователь» и «что получает поисковик» было минимальным, почти нулевым, и именно поэтому о нём никто особенно не думал.

Это условие перестало выполняться незаметно — не в какой-то один момент, а постепенно, по мере того как веб-страницы всё чаще стали работать как приложения. Сейчас достаточно сказать, что разрыв возник — механику и историю этого перехода я разберу в следующей главе. Здесь важнее зафиксировать другое: этот разрыв не устранён и вряд ли будет устранён окончательно. Поисковые системы стали лучше справляться с современным вебом, чем десять лет назад — это можно наблюдать на практике, хотя точную величину этого прогресса я бы не стал оцифровывать: слишком по-разному ведут себя разные краулеры на разных типах сайтов, чтобы говорить об этом одной цифрой. Но справляться лучше не значит справляться полностью и не значит справляться предсказуемо.

Поисковая система как вычислительная среда

Здесь полезно сменить угол зрения на саму поисковую систему. Привычная модель — поисковик как большой каталог, картотека страниц, которую нужно правильно заполнить, — работала, пока страница была статичным объектом. Для современного веба эта модель обманчива. Точнее говорить о поисковой системе как о вычислительной среде: она не просто хранит документы, а постоянно обрабатывает их: обнаруживает, получает, при необходимости рендерит, интерпретирует, сопоставляет с другими сигналами и принимает решения об индексации. Это не единоразовое действие «добавить в базу», а процесс, который может повторяться, откладываться и зависеть от множества факторов, в том числе от доступных поисковой системе ресурсов.

Это смещение — от документа к вычислению — не терминологическая тонкость. Если страница просто хранится, то ошибка — это ошибка в самой странице: опечатка в теге, неправильный статус-код, забытый noindex. Такие ошибки локальны, их видно и легко исправить. Если же представление страницы формируется в процессе обработки, то ошибка может возникать на стыке этапов — между тем, что отдаёт сервер, и тем, что получается после рендеринга; между тем, что заявлено в sitemap. xml, и тем, что реально содержит внутренняя структура; между разными версиями одного URL. Такие проблемы не всегда локальны. Их не видно при обычном просмотре сайта — ни пользователем, ни даже специалистом, который открывает страницы в браузере и не находит поводов для жалоб, как это было в примере выше. Их можно увидеть только тогда, когда смотришь на сайт не как на набор страниц, а как на процесс их обнаружения, обработки и выбора поисковой системой.

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

Что это меняет

Если принять эту рамку, то работа с технической стороной сайта перестаёт быть про «правильную разметку одной страницы» и становится про согласованность между несколькими независимыми источниками информации о сайте: тем, что отдаёт сервер, тем, что видно после выполнения JavaScript, тем, что заявляет sitemap, тем, что подтверждает внутренняя перелинковка, тем, что говорят canonical и hreflang. Ни один из этих источников нельзя считать главным. Проблема часто возникает не внутри одного из них, а в зазоре между ними.

Дальше в этой книге я буду возвращаться к этой рамке — при разговоре про рендеринг, про жизненный цикл URL-адреса, про краулинговый бюджет, про структурированные данные. Но начать нужно было именно с неё, а не с истории SEO или перечисления фреймворков, потому что без этого сдвига в понимании остальные главы легко читаются как список инструментов — а это не список инструментов, которые нужно последовательно освоить. Это попытка объяснить, почему техническое SEO вообще стало настолько сложной дисциплиной: мы больше не работаем только с документом, который поисковая система просто скачивает. Работаем мы с системой, которая должна этот документ обнаружить, обработать, интерпретировать и решить, стоит ли включать его в индекс. А значит, следующий вопрос — как мы вообще пришли к ситуации, в которой страница перестала быть просто документом.

Разработчик, который в 2008 году делал сайт, и разработчик, который в 2015 году делал «сайт», решали разные задачи — хотя формально работали с одним и тем же словом.

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

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

Почему это вообще понадобилось

У этого сдвига были вполне конкретные причины, и поисковые системы к ним отношения не имели. Веб-интерфейсы усложнялись — почта, карты, соцсети, панели администрирования — и постоянная перезагрузка всей страницы ради обновления одного блока стала выглядеть архитектурным анахронизмом. Технология, которая сделала такой подход возможным, появилась раньше, чем может показаться: XMLHttpRequest существовал уже в конце девяностых, но особенно заметным подход стал после появления Gmail в 2004 году, который показал возможности обновления интерфейса без полной перезагрузки страницы.

Дальше идея постепенно распространилась по вебу — сначала точечно, отдельными интерактивными блоками на в остальном статичных страницах, затем всё смелее, пока не оформилась в отдельный класс архитектуры — single-page application, SPA: приложение, в котором основная часть интерфейса формируется на стороне клиента, а сервер может отвечать преимущественно за данные, а не за готовую разметку. AngularJS, впервые выпущенный Google в 2010 году, стал одним из первых массовых фреймворков, закрепивших такой подход. Это был самостоятельный проект, а не ранняя версия современного Angular, но именно вокруг AngularJS во многом сформировалась привычка строить веб-интерфейсы как приложения. React, впервые опубликованный в 2013 году, закрепил эту модель ещё сильнее и сделал компонентный подход к интерфейсам массовым.

С точки зрения продукта и разработки это было настоящим прогрессом, и я не хочу делать вид, что предпочёл бы вернуться назад. Интерфейсы стали отзывчивее. Границы между «сайтом» и «приложением» во многих случаях стали менее определёнными — что для многих продуктов было именно тем, что требовалось. Фронтенд-разработка отделилась в собственную дисциплину со своими инструментами, тестами, экосистемой пакетов. Всё это правда.

Побочный эффект, который редко попадал в повестку

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

А для поисковой системы контентная модель поменялась радикально. Раньше документ приходил цельным — HTML со всем содержимым внутри, который можно было скачать и разобрать сразу. Теперь в некоторых архитектурах по тому же URL приходила минимальная оболочка, а значительная часть контента появлялась только после выполнения JavaScript — то есть требовал не только загрузки HTML, но и дополнительной обработки: выполнения JavaScript, загрузки необходимых ресурсов, запросов к API и формирования итогового состояния страницы. Обработка одного URL, которая раньше во многих случаях сводилась к получению готового документа, стала включать существенно больше шагов: получить оболочку, загрузить необходимые ресурсы, выполнить JavaScript, дождаться необходимых сетевых запросов и сформировать итоговое состояние страницы. Не всегда именно в такой последовательности и не всегда с одинаковой ценой — современные системы умеют часть этого процесса оптимизировать и кэшировать, — но сама обработка стала многоступенчатой там, где раньше во многих случаях была существенно проще.

Одна из самых показательных иллюстраций этого разрыва — документированная история конца 2000-х и начала 2010-х. В 2009 году Google предложил индустрии временное соглашение для индексации AJAX-контента: сайты могли использовать в URL «hash-bang» — site.com/#!/page — и параллельно отдавать краулеру по специальному адресу (?_escaped_fragment_=…) заранее отрисованную HTML-версию той же страницы. Схема работала в браузере как обычная client-side маршрутизация, а для поисковика требовала отдельного, недёшево поддерживаемого механизма подготовки статичных копий. Twitter одно время использовал hash-bang URL в собственном интерфейсе — и в мае 2012 года публично объявил об отказе от них и переходе к History API и pushState (), связывая это в том числе с улучшением скорости загрузки. Сам же Google отказался от предложенной им схемы позже и более концептуально: в октябре 2015 года компания официально депрекировала AJAX crawling scheme, заявив, что Googlebot к этому моменту уже мог обрабатывать JavaScript-страницы значительно эффективнее, чем раньше — поэтому необходимость в отдельном протоколе постепенно исчезла.

Здесь я намеренно не привожу цифру вроде «столько-то процентов SPA-сайтов теряли трафик» — такой статистики, которой я бы доверял, я не нашёл, а множество случайных цифр из блогов той эпохи не выдерживают проверки на источник. Достаточно того, что сама категория проблемы была настолько распространена, что вокруг неё выросла отдельная профессиональная тема — «SEO для JavaScript-сайтов» — и отдельный набор паттернов, часть из которых, включая hash-bang, впоследствии перестала использоваться как основной подход.

Индустрия не стояла на месте

Реакция на этот разрыв не была единой и не появилась мгновенно. Одни команды пытались добиться того, чтобы поисковая система получала примерно то же содержимое, которое видел браузер, — через предварительный рендеринг и специальные сервисы, отдававшие поисковому роботу заранее сформированную версию страницы. Другие начали пересматривать саму архитектуру рендеринга: если проблема в том, что HTML собирается в браузере пользователя, так почему бы не собирать его раньше — на сервере, до того как запрос вообще дойдёт до клиента?

Из этой развилки выросло то, что сегодня называют разными моделями рендеринга —серверный рендеринг (server-side rendering, SSR), генерация статических страниц (static site generation, SSG), инкрементальная генерация статических страниц (incremental static regeneration, ISR), гибридные схемы, где разные части сайта могут использовать разные модели рендеринга. Это не история фреймворков ради истории фреймворков: это история того, как индустрия несколько раз подряд пересматривала один и тот же вопрос — где именно и в какой момент документ, который в итоге увидит пользователь и попытается разобрать поисковик, должен формироваться. Этому вопросу и тому, что каждый из ответов на него значит для SEO, посвящена отдельная глава — четвёртая.

Но прежде чем переходить к моделям рендеринга, стоит остановиться на том, с чем именно сталкивается поисковый робот, когда встречает JavaScript-сайт сегодня — не в 2012 году, а сейчас. Потому что за прошедшее десятилетие поисковые системы тоже не стояли на месте, и разрыв, о котором шла речь в этой главе, сузился — но не закрылся. Где именно проходит его нынешняя граница — тема следующей главы.

«Google давно умеет рендерить JavaScript, так что это больше не проблема» — фраза, которую я слышал десятки раз, обычно от разработчиков, которые искренне не понимают, почему SEO-специалист продолжает задавать вопросы про рендеринг. И в этой фразе есть правда. Проблема в том, что правда в ней — примерно наполовину.

Google действительно умеет обрабатывать JavaScript и рендерить страницы с его использованием. С 2019 Googlebot использует регулярно обновляемую (evergreen) версию Chromium, которая регулярно обновляется вместе с актуальным Chrome — это завершило длительный период, когда Googlebot работал с устаревшим движком рендеринга и не поддерживал часть современного синтаксиса и API. Сегодняшний Googlebot в этом смысле значительно ближе к современному браузеру, чем несколько лет назад. Но «умеет рендерить» и «рендерит сразу, для каждой страницы, без потерь» — не одно и то же. Именно в зазоре между этими двумя утверждениями и живёт большая часть современных проблем JavaScript-SEO.

Между обходом и индексацией есть ещё один этап

По официальному описанию Google, обработка страницы состоит из нескольких последовательных этапов: обход, рендеринг и индексация — не одно действие, а конвейер. Сначала Googlebot получает HTML-ответ сервера и обрабатывает содержащиеся в нём ссылки, текст, метаданные и другие доступные без выполнения JavaScript данные. Если контент уже присутствует на этом этапе — например, страница отрисована на сервере, — индексация может произойти прямо здесь, без дополнительных шагов. Если же значимая часть контента появляется только после выполнения JavaScript, страница попадает в очередь на рендеринг, и лишь когда до неё доходит очередь, специальный сервис Google, Web Rendering Service, обрабатывает её в среде на базе Chromium, выполняет код, выполняет необходимые для обработки сетевые запросы и передаёт получившийся DOM обратно на индексацию.

В индустрии эту последовательность часто называют «двумя волнами индексации» — но стоит сразу оговориться: это не термин самого Google, а удобное разговорное обозначение, которое прижилось среди практиков. Сути это не меняет: между первичной обработкой HTML и последующим рендерингом существует временной разрыв, и этот разрыв не гарантированно мал. В официальной документации Google формулировка сознательно расплывчата: страница может находиться в очереди на рендеринг некоторое время, а иногда и дольше. Я бы не стал переводить это в конкретные часы или дни — слишком по-разному это выглядит на практике в зависимости от масштаба сайта и текущей загрузки инфраструктуры Google, а более точных универсальных сроков сам Google не публикует. Но сам факт очереди — не гипотеза, а задокументированное поведение системы.

Где именно сегодня возникают ограничения

Если раньше главная проблема звучала грубо — «Google вообще не видит JS-контент», — то сегодняшняя картина стала значительно сложнее и не менее важна: рендеринг в целом работает, но обработка конкретной страницы может завершиться без получения части нужного содержимого по вполне предсказуемым причинам.

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

Вторая — отсутствие пользовательского поведения. Google не рассчитывает на обычное пользовательское взаимодействие со страницей: не следует считать клики, прокрутку или наведение курсора гарантированным способом загрузки критичного содержимого. Контент, который появляется по этим действиям — «ленивая» подгрузка по скроллу, раскрывающиеся по клику блоки, — поисковая система может не получить, если он не реализован так, чтобы срабатывать и без событий пользователя.

Третья — статус-коды и директивы, которые могут повлиять на дальнейшую обработку страницы. Здесь у меня будет отсылка чуть вперёд по времени, чем обычно уместно в этой главе, но она важна: в декабре 2025 года Google уточнил в документации, что страницы с некоторыми не-200 статус-кодами, например страницы с ответом 404, могут не проходить этап рендеринга. Для JavaScript-сайтов это особенно важно при работе с ошибками и «мягкими» 404: если сервер возвращает ошибочный статус-код, не стоит рассчитывать, что последующий JavaScript-рендеринг изменит решение поисковой системы об обработке страницы.

С noindex ситуация похожая, но здесь особенно важно не делать слишком широких выводов: если директива noindex присутствует уже в исходном HTML, Google может не выполнять дальнейший рендеринг страницы. Это особенно важно для JS-сайтов: рассчитывать на то, что JavaScript позже удалит или изменит исходный noindex, не стоит — решение может быть принято раньше, чем этот код вообще выполнится.

етвёртая, и одна из самых распространённых, — заблокированные ресурсы. Файл robots. txt, запрещающий поисковому роботу доступ к файлам JavaScript или CSS, необходимых для построения страницы, может лишить рендерер ресурсов, необходимых для корректного построения и понимания страницы: он получает доступ к HTML-странице, но не может загрузить часть ресурсов, необходимых для её формирования. Об этом предупреждают едва ли не в каждом гайде по JavaScript SEO уже лет десять — и тем не менее эта ошибка продолжает встречаться на реальных аудитах с завидной регулярностью, что скорее говорит не о недостатке информации, а о том, что проверка robots. txt на блокировку критичных ресурсов до сих пор не всегда входит в технический аудит наравне с проверкой доступности самих страниц.

Наконец, доступность ресурса ещё не означает, что Google обязательно будет его загружать. Google прямо указывает, что Googlebot и Web Rendering Service могут не запрашивать ресурсы, которые не считает необходимыми для обработки основного содержимого страницы. Для разработчика это важное различие: «ресурс доступен поисковику» и «поисковик обязательно загрузит этот ресурс при обработке страницы» — не одно и то же. Нет смысла полагаться на первое как на гарантию второго.