Сколько Google сканирует, индексирует и заново ранжирует страницы: собственные сроки Google из Барселоны

2 октября 2026 года, в последний день Search Central Live Deep Dive в Барселоне, Gary Illyes из Google показал три слайда под названием «Сколько времени занимает…»: сканирование, индексирование и показ в выдаче. Каждый слайд перечислял процессы Google с минимальным, обычным и самым долгим временем, взятым из внутреннего анализа Google. John Campbell из агентства ROAST был в зале и в тот же день опубликовал таблицы. Он назвал это совершенно новой информацией, и для всякого, кто на вопрос «когда Google это подхватит?» отвечал «всё зависит от обстоятельств», так оно и есть.

Когда таблицы разошлись по сети, Gary сказал Barry Schwartz, что слайды были «упражнением, чтобы проверить, откликаются ли у аудитории цифры, которые мы получили из внутренних данных» (Search Engine Roundtable). Мы читали их в этом духе: поставили каждую строку рядом с тем, что говорит документация Google, сверили заявленные сроки развёртывания обновлений с Search Status Dashboard и сравнили таблицы ROAST с двумя другими записями участников. Получился разбор того, что значат эти цифры, где они расходятся с письменными рекомендациями Google и сколько ждать после изменений на сайте малого бизнеса. Остальное из третьего дня мы кратко пересказываем в конце.

Что Google показал в Барселоне?

Gary Illyes показал, сколько времени занимают 23 процесса Google (сканирование, индексирование, показ в выдаче): для каждого дано минимальное, обычное и самое долгое время. Обычное время у большинства короткое, от нескольких часов до нескольких недель. Самые долгие сроки растягиваются на месяцы и до года, а в пяти процессах встречается «никогда».

На каждом слайде процессы располагались на шкале от секунд до года. В ROAST перенесли столбцы «обычно» и «дольше всего» в три таблицы, а Search Engine Roundtable, Search Engine Journal, PPC Land и другие за несколько дней перепечатали их. Минимальные значения в таблицы не вошли, но их видно на фото слайда об индексировании от ROAST ниже, вместе со сноской: сроки «основаны на внутреннем анализе».

Две другие записи участников от ROAST не зависят. Ibrahim Anjro собрал по записи выступления и слайдам открытую базу знаний мероприятия, а Liv Day из Digitaloft написала краткий обзор. Обе совпадают с ROAST по всем обычным цифрам, которые они приводят, хотя Digitaloft охватывает лишь около половины строк. Автор базы знаний отмечает своими словами, что время обнаружения усреднено «по всем известным ему сайтам» и что Gary назвал среднее индексирование в 1,5 часа «вероятно, заниженным из-за смещения выборки, потому что очень много новостных сайтов выпускают статьи». Gary также подчеркнул, что процессы выстроены в цепочку. Страница не попадёт в индекс, пока её не просканируют, поэтому задержки складываются.

Google не сказал, какие сайты и какой период описывают «обычные» значения. На этот пробел указал Search Engine Journal. Мы читаем их так: это средние по всему вебу, сдвинутые к быстрому краю крупными сайтами, которые публикуют материалы весь день. Сайт малого бизнеса с несколькими десятками страниц скорее окажется ближе к медленному краю каждой строки.

Сколько времени занимает сканирование?

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

Для малого бизнеса важнее всего строка о повторном сканировании. Если поменять цену, номер телефона или часы работы на странице, которую Google посещает редко, её сохранённая копия может месяц и дольше оставаться устаревшей. Через пять дней после мероприятия в ROAST опубликовали данные собственного сайта: по 178 URL, которые проверяли каждый день в течение 30 дней, среднее время с тех пор, как Google в последний раз просканировал страницу, составило 39,2 дня. У главной страницы отставание было 1,6 дня. Это один сайт агентства, но он показывает, насколько сильно отдельный сайт может отклониться от 30 дней, средних по вебу.

Для страниц, которые действительно меняются, Инструмент проверки URL позволяет запросить индексирование одного URL за раз, хотя в руководстве Google по повторному сканированию сказано, что есть квота и что повторный запрос для того же URL «не ускорит его сканирование». Файл Sitemap охватывает весь сайт, но дату lastmod Google учитывает, только если она «стабильно и проверяемо» точна. CMS, которая каждый день проставляет на каждой странице сегодняшнюю дату, даёт Google повод игнорировать это поле.

Только в строке про robots.txt слайд и документация сходятся в обычном времени, 24 часа, хотя документация добавляет, что Google может хранить кэшированную копию дольше, если обновление не удалось. Если вы разблокировали что-то важное, вы можете попросить Google загрузить файл заново через отчёт о robots.txt, но, как предупреждает Google, это «не гарантирует немедленного повторного сканирования разблокированных URL».

Лимит скорости сканирования стоит помнить перед распродажей или сменой хостинга. По данным ROAST, он может упасть за секунды, когда Google сбавляет обороты, а на слайде восстановление занимает от одной до трёх недель. Руководство Google по бюджету сканирования называет причину: когда сайт замедляется или отвечает ошибками 5xx или 429, «лимит снижается, и Google сканирует меньше». В первый день того же мероприятия докладчики Google назвали растущими проблемами CDN, которые блокируют Googlebot, и страницы с проверкой, возвращающие 200 OK (ROAST, день 1). По цифрам слайда, правило файрвола, которое на одни выходные принимает Googlebot за атаку, может обернуться неделями замедленного сканирования.

Сколько времени занимает индексирование?

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

Эти 1,5 часа и «примерно сутки» со справочной страницы, вероятно, измеряют разное. ROAST объясняет, что «от начала до конца» значит «все критические процессы завершились успешно». Справочная страница описывает то, что видит владелец сайта после запроса на индексирование, включая ожидание сканирования. Добавьте замечание Gary о новостных сайтах, и обе цифры могут быть верными одновременно.

Малые сайты сталкиваются именно с медленным краем этой строки. В отчёте «Индексирование страниц» статус «Crawled - currently not indexed» означает, что Google загрузил страницу и не включил её в индекс; Google пишет, что она «может быть проиндексирована в будущем, а может и нет» и что отправлять её повторно не нужно. Когда владелец сайта пожаловался в 2025 году, что на сайте возрастом в несколько месяцев в индексе только четыре страницы, John Mueller ответил, что «часто это признак того, что наши системы не уверены в сайте в целом». Инструменты, которые отслеживают индексирование, тоже видят длинный хвост: IndexCheckr, который продаёт такой инструмент, сообщает о среднем сроке 27,4 дня для страниц, которые отслеживают его пользователи, считая с начала отслеживания.

С переездами сайтов всё наоборот. В руководстве Google сказано, что «на перенос большинства страниц малого или среднего сайта может уйти несколько недель, а крупным сайтам нужно больше времени». По минимуму слайд с руководством сходится: на фото он записан как «несколько недель (малый)». Но обычный переезд слайд ставит на один-три месяца, а самый долгий на срок от шести месяцев до года и больше. В том же руководстве советуют сохранять перенаправления «как правило, не менее 1 года». У трафика свои часы. В исследовании 892 переездов доменов, которое провёл Dan Taylor из агентства 10 Spurs, новому домену потребовалось в среднем 523 дня, чтобы вернуть органический трафик старого. В исследовании использовались сторонние оценки трафика и краудсорсинговая выборка, поэтому его среднее больше говорит о риске, чем о каком-либо отдельном сайте.

Для смены канонической страницы самый долгий случай на слайде сам называет причину: противоречивые сигналы. Когда канонический тег указывает на один URL, внутренние ссылки и файл Sitemap на другой, а перенаправление на третий, Google нужны месяцы, чтобы определиться. Во второй день John Mueller советовал использовать перенаправления при переезде сайта и сохранять ясные канонические сигналы (ROAST, день 2). У структурированных данных то же «или никогда», что и у индексирования: разметка на странице, которую Google оценивает низко, может так и не превратиться в расширенный результат, как бы корректна она ни была.

Через сколько изменения появляются в выдаче?

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

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

Реалистичная цифра важнее всего при восстановлении после core update. На странице Google об основных обновлениях сказано, что часть изменений «может вступить в силу за несколько дней, но может потребоваться несколько месяцев», а если за несколько месяцев эффекта нет, «это может означать ожидание следующего core update». База знаний фиксирует оговорку, которую потеряла таблица ROAST: восстановление занимает от трёх до шести месяцев «после того, как сайт проделает работу по возврату трафика», то есть отсчёт начинается, когда исправления внесены. Прошлые случаи показывают, что и этот срок может оказаться оптимистичным: после helpful content update в сентябре 2023 года Search Engine Roundtable сообщил о первых восстановлениях лишь с августовским core update 2024 года, спустя одиннадцать месяцев, а Glenn Gabe насчитал 47 сайтов с ростом среди 380+, за которыми он следит.

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

Сколько длится развёртывание основных и антиспам-обновлений?

В таблицах ROAST основные обновления разворачиваются за две-четыре недели, антиспам-обновления за один-два дня. Собственный Search Status Dashboard Google показывает больший разброс: девять core update с марта 2024 года заняли от 6 до 45 дней, а восемь spam update от 19,5 часа почти до четырёх недель.

Четыре из девяти основных обновлений уложились в две-четыре недели. Из четырёх антиспам-обновлений 2026 года два оказались близки к одному-двум дням из таблиц ROAST: мартовское заняло 19,5 часа, июньское два дня. Августовское заняло 2 дня и 16 часов, а сентябрьское шло 13 дней и 16 часов; Gary выступал через восемь дней после его начала, как отметил PPC Land. Собственные заметки Google о запуске на дашборде осторожны: «может занять до 2 недель», «до 3 недель», «до месяца».

База знаний читает ту же строку на слайде иначе: основное обновление затрагивает сайт в течение двух-четырёх недель с начала развёртывания, а антиспам-обновление в течение одного-двух дней. При таком прочтении слайд описывает, когда сайт ощущает изменение, и приведённые выше сроки по дашборду ему не противоречат. Мы проверили формулировку ROAST, потому что именно она распространилась.

Для собственного анализа самая полезная из опубликованных Google цифр по-прежнему та, что на странице об основных обновлениях: подождите «не менее полной недели после завершения core update», прежде чем читать данные в Search Console.

Почему слово «никогда» встречается так часто?

«Никогда» на слайдах стоит у обнаружения, повторного сканирования, файлов Sitemap, индексирования и структурированных данных; ROAST обычно связывает его с качеством. Быстрый сервер не спасёт страницу, которую Google не считает достойной хранения. Руководство Google о том, как работает Поиск говорит прямо: Google «не гарантирует, что просканирует, проиндексирует или покажет вашу страницу».

Duy Nguyen, аналитик по качеству поиска в Google, выступал с докладом о качестве раньше в тот же день. Он описал качество как сотни сигналов, которые различаются по типу результата, причём Google постоянно тестирует изменения, и посоветовал прочитать общедоступную инструкцию для асессоров, в которой контент оценивают по усилиям, оригинальности, таланту или мастерству и точности. Эти четыре слова появились в руководстве Google о полезном контенте 1 октября, за день до того; об этом изменении мы писали в статье об основном контенте. Он также сказал, что Google оценивает качество страницы независимо от того, кто её написал. Низкое качество бывает и у контента, написанного человеком, и у созданного AI, а правила Google о спаме называют массовое производство страниц злоупотреблением масштабируемым контентом, «независимо от способа создания».

Gary завершил утреннюю часть одной цифрой: Google отсеивает 40 миллиардов спамных страниц в день. Впервые эта цифра появилась в отчёте Google о борьбе со спамом за 2020 год, опубликованном в апреле 2021 года («каждый день мы обнаруживаем 40 миллиардов спамных страниц»), а ранее, в отчёте за 2019 год, было 25 миллиардов. Страница Google «Как работает Поиск» о спаме по-прежнему использует её, а более свежего подсчёта мы не нашли. Его предупреждение, что массовый контент теперь создаёт больше проблем, чем ссылочный спам, прозвучало без опубликованных данных, поэтому это оценка изнутри команды.

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

Где слайд и документация Google расходятся

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

• Индексирование: около 1,5 часа на слайде, «примерно сутки» и «до одной-двух недель» на справочных страницах.
• Переезд сайта: на слайде обычно от одного до трёх месяцев, в руководстве для малых и средних сайтов «несколько недель».
• noindex и другие мета-аннотации: на слайде не более четырёх дней, а документация предупреждает, что повторное посещение «может занять месяцы». Обе цифры могут быть верными, если слайд отсчитывает от момента повторного сканирования.
• Развёртывание, как ROAST читает слайд: две-четыре недели для основных обновлений и один-два дня для антиспам-обновлений; на дашборде от 6 до 45 дней и от 19,5 часа почти до четырёх недель.
• Уровень страницы: на сцене «не на уровне домена»; в руководстве сигналы уровня всего сайта «также используются».

Записи участников тоже расходятся в одном месте: для аннотаций ссылок ROAST указывает самым долгим сроком «месяцы», а база знаний читает конечную точку на слайде как около одного года.

Как мы читаем этот разрыв: документация написана так, чтобы быть безопасной для любого сайта, и пересматривается редко, а слайд показывает измеренные средние по всему вебу. Ни то ни другое ничего не обещает вашему сайту.

Что ещё Google сказал в третий день

Кроме сроков, в третий день обсуждали, как Google читает запрос, оценивает качество и спам, как контент попадает в Discover, а также новые данные о товарах для AI-покупок и Search Console. Большая часть совпадает с уже опубликованным. Несколько пунктов, в основном о переписывании запросов, пока известны только по словам со сцены.

John Mueller начал с того, как Google понимает запрос. Google определяет язык, отбрасывает стоп-слова, если они не входят в название, распознаёт сущности и расширяет синонимы, поэтому запрос «fried chicken place in barcelona» ищется так, как будто в нём написано place OR area OR location OR restaurant. Некоторые синонимы зависят от контекста: GM рядом со словом «car» означает General Motors, а рядом со словом «barley» genetically modified. «Siblings» (родственные понятия), например Canon и Nikon, Google узнаёт из поисков людей «X vs Y» и держит раздельно. В How Search Works упоминается «сложная система синонимов», но о siblings и о переписывании в духе OR мы не нашли ни в одном документе. Для AI Overviews и AI Mode модель добавляет query fan-out (разветвление запроса на несколько связанных поисков), которое страница Google об AI-функциях описывает как «выполнение нескольких связанных поисковых запросов по подтемам и источникам данных». Mueller сказал, что запросы fan-out не видны в Search Console, потому что их не вводят пользователи. Затем Gary объяснил отбор: перед ранжированием Google сужает индекс до страниц-кандидатов (на этом шаге важными сигналами служат язык и страна), а окончательное решение принимает качество.

Eric Murillo, который отвечает в Google за доверие и безопасность в Discover, сказал, что специального бота для Discover нет: контент берётся из обычного индекса и проходит фильтр допуска. Его советы по изображениям совпадают с документацией Google о Discover строка в строку: шириной не менее 1200 px, больше 300 000 пикселей, соотношение сторон 16:9 и max-image-preview:large. Всё остальное о Discover есть в нашем руководстве по Discover.

Alex Jansen, инженер-программист Google, представил conversational attributes (разговорные атрибуты) для покупок. Они описаны в документации: шесть необязательных атрибутов Merchant Center, объявленных 20 мая 2026 года, которые «помогают системам AI и разговорным агентам лучше понимать особенности ваших товаров» (справка Merchant Center). Пример с чайником он взял у самого Google: на справочной странице атрибута «вопрос и ответ» приведён чайник для чая с пятью частыми вопросами. Он также обратил внимание на product highlights (выделенные особенности товара): к каждому товару можно добавить от 2 до 100 таких пунктов, и Google рекомендует от четырёх до шести.

Ariel Kroszynski, который руководит фронтенд-разработкой Search Console, рассказал о событиях прошедшего года: группы запросов в отчёте Insights (октябрь 2025 года, только для ресурсов с большим числом запросов), настройка с помощью AI отчёта об эффективности (декабрь 2025 года, сначала для ограниченного набора сайтов) и мультимодальная веб-отчётность (web multimodal) (24 сентября 2026 года). ROAST пишет, что обновлений по отчётности о генеративном AI не было. Это значит, что ничего нового не объявили: отчёт Generative AI performance report существует с 3 июня 2026 года, а 31 августа стал доступен всем сайтам. Он показывает, как часто ваши страницы появлялись в AI Overviews и AI Mode, по страницам, странам, устройствам и датам, без данных о запросах, что согласуется со словами Mueller о fan-out.

Pablo Pérez, старший менеджер по маркетинговым исследованиям и аналитике в Google, вернулся к модели Messy Middle 2020 года, в которой покупатели циклично переходят от изучения к оценке и обратно. Новое в его выступлении: AI позволяет людям дольше изучать товар перед покупкой, а интерес британцев к поисковому запросу «is [brand] legit» с 2020 года растёт и достиг пика в 2026 году. Проверить этот ряд сами мы не смогли: он взят из выступления.

Gary завершил три дня словами, что AI-функции в Google Поиске используют те же процессы, что и традиционные результаты. Руководство Google по генеративным AI-функциям говорит то же письменно: оптимизация под генеративный AI-поиск «это оптимизация под поисковый опыт, а значит, по-прежнему SEO». Эту позицию мы разбирали в статье «Хороший SEO это хороший GEO».

Что принесли на сцену практики

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

• Robert Wojno из Hostinger сравнил общее руководство «What is VPS hosting?» с 1,6 млн показов и узкое руководство по запуску сервера Palworld с 46 000. У узкой страницы CTR оказался в 23 раза выше, и она лучше конвертировала.
• Juan Seguí из acceseo добавил подробные FAQ с ответами на вопросы, которые задают настоящие родители, например, поместится ли двойная коляска в лифт вместе с родителем. Органические клики выросли на 14%, а вопросов к команде перед покупкой стало меньше.
• Noe Rivas из seosve дополнил страницу видео для тех, кто впервые знакомится с темой, и в итоге страница стала ранжироваться в AI Overviews, Gemini, YouTube и поиске по изображениям.
• Nik Vujic из Get Stuff Digital запускает LLM-агентов на данных Search Console и GA4, чтобы отслеживать, по какому числу запросов каждая статья ранжируется со временем.
• Alex Wright из iDHL показал бренд, у которого органические сеансы упали на 47%, а прямые держались (минус 2%). Число обращений на 100 кликов из поиска выросло в 2,7 раза, доля бренда во всех кликах из поиска поднялась с 17% до 38%, CTR объявлений Google Ads вырос на 36% при неизменной позиции объявления, а 83% его цитирований в AI пришлись на сайты, которые ему не принадлежат.

Для малого бизнеса случай Wright самый полезный: кликов стало меньше, а обращений на клик больше. Значение имеет число заявок в месяц, а клики в Search Console сами по себе могут ввести в заблуждение.

Что это значит для сайта малого бизнеса

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

Сегодня откройте отчёт «Индексирование страниц». Страницы со статусом «Crawled - currently not indexed» пока находятся в колонке «никогда» на слайде, и повторный запрос индексирования их не сдвинет; а вот более сильная страница может. Статус «Discovered - currently not indexed» другое дело: по словам Google, обычно это значит, что сканирование отложили, чтобы не перегружать сайт, поэтому длинный список здесь повод посмотреть на скорость сервера.

На этой неделе проверьте, что CDN или защита от ботов пропускает Googlebot и что страницы с проверкой не возвращают 200 OK. Убедитесь, что даты lastmod в файле Sitemap меняются только тогда, когда меняется страница. Если вы планируете переезд, сохраняйте перенаправления не меньше года и планируйте первые три месяца с оглядкой на переезд.

Дальше записывайте рядом с каждым изменением ожидаемую дату, пользуясь таблицей выше. Тогда медленная неделя не выглядит проблемой, а настоящая проблема не остаётся без внимания на месяцы.

Это средние значения Google. Никто за пределами Google, включая нас, не может пообещать, когда Google просканирует, проиндексирует или заново проранжирует страницу. Аудит может показать, в какой колонке таблицы находятся ваши страницы и почему. Если страницы сидят в «никогда», наш SEO-аудит сайта начинается именно с этого.

Источники

Мероприятие:

• John Campbell, “Google Search Central Live Deep Dive, Barcelona, Day 3 Recap”, ROAST, 2 октября 2026 года: weareroast.com; Day 1, 30 сентября 2026 года: weareroast.com; Day 2, 1 октября 2026 года: weareroast.com
• John Campbell, “How Often Does Google Recrawl Pages? Real Data from the ROAST Website”, ROAST, 7 октября 2026 года: weareroast.com
• Ibrahim Anjro, “Search Central Live Deep Dive Europe 2026: The Knowledge Base”, сессия D3-S17 “How long does it take to..?”, GitHub: github.com
• Liv Day, “Google Search Central Live Deep Dive Europe 2026: A Summary”, Digitaloft, 4 октября 2026 года: digitaloft.co.uk
• Google Search Central Blog, “Search Central Deep Dive Europe 2026”, 6 июля 2026 года: developers.google.com
• Barry Schwartz, “Google Search Data On Crawling, Indexing & Serving Timelines”, Search Engine Roundtable, 5 октября 2026 года: seroundtable.com
• Matt G. Southern, “Google Shows How Long Crawling, Indexing & Recovery Can Take”, Search Engine Journal, 4 октября 2026 года: searchenginejournal.com
• “Google says new pages take about 20 hours to be found, some never are”, PPC Land, 3 октября 2026 года: ppc.land

Документация Google о сканировании, индексировании и показе в выдаче:

• Ask Google to recrawl your URLs: developers.google.com
• URL Inspection tool, Search Console Help: support.google.com
• Page indexing report, Search Console Help: support.google.com
• Build and submit a sitemap: developers.google.com; Sitemaps report, Search Console Help: support.google.com
• How Google interprets the robots.txt specification: developers.google.com; robots.txt report, Search Console Help: support.google.com
• Crawl budget management: developers.google.com; How HTTP status codes affect Google’s crawlers: developers.google.com
• Understand JavaScript SEO basics: developers.google.com
• Block search indexing with noindex: developers.google.com
• How to specify a canonical: developers.google.com
• Site moves and migrations: developers.google.com
• Video indexing report, Search Console Help: support.google.com
• Removals tool, Search Console Help: support.google.com
• Influencing title links: developers.google.com
• Manual actions report, Search Console Help: support.google.com
• Google Search’s core updates: developers.google.com; Google Search spam updates: developers.google.com
• Google Search Status Dashboard, Ranking history, просмотрено 27 октября 2026 года: status.search.google.com
• In-depth guide to how Google Search works: developers.google.com

Google о качестве, спаме и AI-функциях:

• Creating helpful, reliable, people-first content: developers.google.com
• Spam policies for Google web search: developers.google.com
• How we fought Search spam on Google in 2020, 29 апреля 2021 года: developers.google.com; Webspam report 2019, 9 июня 2020 года: developers.google.com
• How Search Works, Detecting spam: google.com; Ranking results: google.com
• A guide to Google Search ranking systems: developers.google.com
• AI features and your website: developers.google.com; Optimizing your website for generative AI features on Google Search: developers.google.com
• Discover and your website: developers.google.com
• Merchant Center Help: conversational attributes support.google.com, question and answer support.google.com, product highlight support.google.com; Google Marketing Live shopping updates, 20 мая 2026 года: blog.google
• Search Central Blog: query groups, октябрь 2025 года developers.google.com; AI-powered configuration, декабрь 2025 года developers.google.com; Generative AI performance reports, 3 июня 2026 года developers.google.com; web multimodal reporting, 24 сентября 2026 года developers.google.com
• Think with Google, “Navigating purchase behavior and decision-making”, июль 2020 года: thinkwithgoogle.com

Независимые данные и практики:

• “Google says poor indexing on strong hosting indicates quality issues”, PPC Land, 16 июля 2025 года: ppc.land
• Joel Cariño, “Google Indexing Study: Insights from 16 Million Pages”, IndexCheckr, 28 февраля 2025 года: indexcheckr.com
• Dan Taylor, “How Long Should An SEO Migration Take? [Study]”, Search Engine Journal, 8 января 2025 года: searchenginejournal.com
• Barry Schwartz, “Reports Of Google Helpful Content Update Resurrections With August 2024 Core Update”, Search Engine Roundtable, август 2024 года: seroundtable.com