Ускоряем индексацию сайта в Google за 14 дней: причины и решения

Страница начинает получать показы в Google после включения в индекс. Если новые услуги и статьи долго остаются в статусах Discovered - currently not indexed или Crawled - currently not indexed, сначала проверяют доступность URL, ответ сервера, robots.txt, noindex, canonical, sitemap, внутренние ссылки и отрендеренный HTML.

План на 14 дней основан на одном проекте Метриум для компании из сферы услуг в Алматы. За этот срок специалисты проверили сайт, исправили шаблоны и передали приоритетные страницы на повторный обход. Срок описывает выполненную работу в конкретном проекте. Google может сканировать URL от нескольких дней до нескольких недель и не гарантирует включение страницы в индекс.

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

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

Статус Discovered - currently not indexed означает, что Google знает адрес, но еще его не просканировал. Статус не сообщает точную причину. Проверка начинается с sitemap, внутренних ссылок, серверных логов, доступности хоста и размера группы URL.

Статус Crawled - currently not indexed означает, что робот получил страницу, но пока не добавил ее в индекс. Здесь проверяют отрендеренный текст, дубли, canonical, soft 404, качество шаблона и соответствие страницы поисковой задаче. Повторный запрос через URL Inspection без исправления причины редко меняет результат.

Индексация также не гарантирует позицию. После включения URL Google отдельно определяет, по каким запросам показывать страницу и насколько высоко ее ранжировать. Технический спринт открывает доступ к обработке страницы, а работа с содержанием и спросом влияет на последующие показы.

Сохраните исходные данные до любого изменения. Нужны экспорт Page Indexing, несколько URL из каждого статуса, результаты URL Inspection, sitemap, robots.txt, коды ответа, серверные логи и снимок rendered HTML. Для каждой группы страниц запишите число опубликованных, обнаруженных, просканированных и проиндексированных адресов.

Оператор site: подходит для быстрой проверки отдельных URL, но его выдача не дает полного числа страниц и не заменяет Search Console. Источником для технического решения служат Page Indexing, URL Inspection, Sitemaps и журналы сервера.

Ошибки проверяют по шаблонам. Если одна страница услуги индексируется, это еще не подтверждает исправность остальных услуг. В CMS могут различаться пустые поля, canonical, meta robots, код ответа и содержимое, загруженное через API.

Таблица задает очередность проверки. Колонка с преждевременным выводом показывает, какое объяснение пока нельзя считать установленной причиной.

Сначала убедитесь, что URL отвечает кодом 200 OK и доступен Googlebot. Затем проверьте robots.txt и директивы noindex. После этого сравните заявленный canonical с выбранным Google. Следующие операции относятся к sitemap, внутренним ссылкам и rendered HTML.

Такая последовательность экономит время. Если страница возвращает 5xx или закрыта через noindex, обсуждение размера sitemap и качества текста преждевременно. Если Google выбирает другой canonical, перед повторным запросом нужно привести редиректы, ссылки и карту сайта к одной основной версии.

Sitemap сообщает Google о важных URL и дате их существенного изменения. В файл включают канонические страницы с ответом 200 OK, доступные для индексирования. Страницы с редиректами, noindex, 404, 410 и технические дубли из sitemap удаляют.

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

URL Inspection используют для проверки отдельной страницы: Google видит URL или нет, разрешено ли индексирование, какой canonical выбран и что попало в rendered HTML. После существенного исправления через инструмент можно запросить повторный обход нескольких приоритетных страниц.

Официальный срок повторного сканирования составляет от нескольких дней до нескольких недель. Повторная отправка того же URL процесс не ускоряет. Большой список страниц передают через обновленный sitemap. Request Indexing используют для нескольких приоритетных адресов.

Robots.txt ограничивает сканирование URL. Директива noindex исключает страницу из индекса после того, как Googlebot получит HTML или HTTP-заголовок. Если закрыть URL через Disallow, робот может не прочитать noindex.

Для окончательно удаленной страницы без подходящей замены возвращают 404 Not Found или 410 Gone. Google рассматривает оба кода как сигнал отсутствующего содержимого. Если страница переехала, на актуальный URL ставят 301. Редирект всех удаленных страниц на главную может быть распознан как soft 404.

Внутренние ссылки и sitemap очищают от удаленных адресов. При этом нормальные 404 сами по себе не ухудшают позиции работающих страниц. Риск возникает, когда нужный товар или услуга ошибочно отвечает 404, когда пустой шаблон возвращает 200 либо когда навигация ведет на множество отсутствующих URL.

Google выбирает canonical по совокупности сигналов. Тег rel="canonical" важен, но его поддерживают редиректы, внутренние ссылки, sitemap и сходство содержимого. Если в sitemap указан один URL, навигация ведет на второй, а canonical указывает на третий, выбор Google трудно прогнозировать.

Проверьте HTTP и HTTPS, www, слеши, параметры аналитики, сортировки, фильтры и страницы печати. Основная версия должна получать внутренние ссылки и входить в sitemap. Старые версии после переноса направляют на нее одним редиректом.

Для каждой группы дублей сохраняют правило. Например, UTM-метки не создают отдельную посадочную страницу, а региональная услуга с уникальными условиями и содержанием может иметь собственный canonical. Автоматическое сведение всех параметров к одной странице способно скрыть нужные категории.

Google выполняет JavaScript и видит содержимое после рендеринга, но у этого процесса есть ограничения. Страница может загрузить текст в браузере пользователя и при этом отдать Googlebot пустой исходный HTML, ошибку API или неполную версию.

Основной текст и ссылки надежнее отдавать в HTML через SSR, SSG или предварительный рендер. В URL Inspection сравните код ответа, заголовок, canonical, meta robots, текст и ссылки с тем, что показывает обычный браузер. Серверные логи дополняют проверку: по ним видно, запрашивал ли Googlebot HTML и ресурсы.

Dynamic rendering Google называет временным обходным способом. Для постоянного решения Google рекомендует server-side rendering, static rendering или hydration. Клиентский JavaScript допустим, если поисковик стабильно получает основной текст и ссылки в rendered HTML.

Руководство Google по crawl budget предназначено в первую очередь для сайтов примерно от миллиона страниц, ресурсов от 10 000 быстро меняющихся страниц и сайтов с большой долей статуса Discovered - currently not indexed. Эти числа Google называет приблизительными.

Для сайта из 50 страниц сначала проверяют ответы сервера, robots.txt, noindex, canonical, sitemap, внутренние ссылки и фактический HTML. Диагноз нехватки crawl budget требует серверных логов и данных Search Console. Само число исключенных URL его не подтверждает.

На большом каталоге отдельная работа с обходом может быть оправдана. Тогда удаляют бесконечные параметры и дубли, поддерживают актуальный sitemap, сокращают цепочки редиректов, исправляют soft 404, ускоряют сервер и используют корректный ответ 304 Not Modified для ранее просмотренного неизменившегося содержимого.

Код 304 экономит ресурсы сервера и сообщает Google использовать сохраненную версию. Он не ускоряет индексацию нового URL. Новая или измененная страница должна вернуть актуальное содержимое с кодом 200 OK.

Indexing API Google предназначен для страниц с JobPosting и BroadcastEvent внутри VideoObject. Статья, карточка товара или страница услуги не входит в этот перечень.

Ответ API подтверждает принятие уведомления. Он не сообщает дату включения URL в индекс. Для обычного сайта применяют внутренние ссылки, sitemap, URL Inspection и контроль Page Indexing. Сервисы с обещанием мгновенной массовой индексации не заменяют исправление robots.txt, canonical, серверных кодов и rendered HTML.

Календарь ниже подходит для сайта, где требуется аудит нескольких шаблонов и участие разработчика. Если на первом дне найдена массовая ошибка 5xx или noindex, ее исправляют сразу, а остальные задачи сдвигают.

В одном из проектов Метриум для компании из сферы услуг в Алматы работали с новым доменом, 30 страницами услуг и 20 статьями. На старте sitemap объединял все адреса в одном файле, часть страниц отвечала кодом 200 с пустым шаблоном, внутренние ссылки были распределены бессистемно, а основной текст загружался на клиенте.

В первые два дня страницы разделили по типам, исправили robots.txt, создали навигационные страницы услуг и блога, добавили ссылки на приоритетные URL и привели canonical к основным версиям. Редиректные адреса удалили из sitemap.

На 3-5 день критические шаблоны перевели на SSR, а текстовые блоки добавили в исходный HTML. Результат проверили через URL Inspection. На 6-8 день исправили soft 404 и пустые страницы, сократили число технических параметров. На 9-11 день добавили ссылки из статей на услуги и обновили lastmod у реально измененных URL. На 12-14 день передали на повторный обход несколько страниц, проверили canonical и сохранили статусы.

Первая группа страниц услуг появилась в индексе до конца первой недели. Статьи начали входить в индекс на второй неделе. После завершения работ новые материалы на этом сайте обычно индексировались за 1-3 дня.

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

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

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

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

Массовая смена canonical способна вывести из индекса нужные региональные или товарные страницы. Перед применением правила проверяют поисковую задачу каждого шаблона и несколько реальных URL.

Закрытие параметров через robots.txt может оставить известные Google адреса в очереди без возможности прочитать noindex. Для дублей выбирают метод по ситуации: canonical, редирект, noindex, изменение архитектуры или запрет обхода.

Перевод сайта на SSR без проверки кэша может вернуть старый текст и metadata. После внедрения сравнивают исходный HTML, браузер и Live test. Новый код также проверяют на 5xx и рост времени ответа.

Удаление страниц из sitemap не удаляет их из индекса. Sitemap сообщает о важных URL, а удаленные страницы должны вернуть корректный код, noindex либо релевантный редирект. Внутренние ссылки также обновляют.

Sitemap сообщает Google о важных URL и упрощает их обнаружение. Файл не гарантирует сканирование и индексацию. Страницы должны отвечать 200, быть открытыми, указывать на правильный canonical, содержать основной текст и получать внутренние ссылки.

Google называет срок от нескольких дней до нескольких недель. Повторный запрос того же URL не ускоряет процесс. Следует проверить дату последнего обхода, выбранный canonical и статус Page Indexing после исправлений.

Google сопоставляет тег canonical, редиректы, sitemap, внутренние ссылки и сходство страниц. Если сигналы расходятся, поисковик может выбрать другую основную версию. Все источники URL нужно привести к одному адресу и повторно проверить обе страницы.

Google выполняет JavaScript, но основной текст и ссылки должны присутствовать в rendered HTML. Для критических страниц надежнее SSR, SSG или предварительный рендер. Решение принимают после Live test и проверки серверных логов.

Для небольшого сайта сначала проверяют ответы сервера, robots.txt, noindex, canonical, sitemap, внутренние ссылки и HTML. Отдельный диагноз crawl budget требует данных, которые показывают дефицит обхода.

Google ограничивает Indexing API страницами с JobPosting и BroadcastEvent внутри VideoObject. Обычные страницы передают через sitemap, внутренние ссылки и URL Inspection.

Четырнадцать дней описывают срок работ в одном проекте Метриум. За этот период можно провести аудит, исправить шаблоны, передать приоритетные URL и поставить их на контроль. Дата обхода и включения в индекс зависит от Google.

Проверку следует начинать с выборки URL и исходных статусов Search Console. Это отделяет массовую ошибку шаблона от задержки отдельных страниц и дает разработчику точный перечень работ.

Метриум проверит индексируемость сайта, сопоставит Page Indexing с кодами ответа и rendered HTML, затем подготовит задачи по шаблонам. Проверить индексируемость сайта.

Для Яндекса действует отдельный набор инструментов и сроков. Он разобран в статье «Ускорьте индексацию в Яндексе за 30 дней».

1. Google Search Central: запрос повторного обхода.
2. Google Search Central: назначение sitemap.
3. Google Search Central: оптимизация crawl budget.
4. Google Search Central: dynamic rendering.
5. Google Search Central: Indexing API.