Скільки часу 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 про повторне сканування зазначає, що існує квота і що повторний запит для тієї самої адреси «не прискорить її сканування». Файл Sitemap охоплює весь сайт, але дату lastmod Google враховує лише тоді, коли вона «послідовно й підтверджувано» точна. CMS, яка щодня ставить сьогоднішню дату на кожну сторінку, дає Google привід ігнорувати це поле.

Рядок про robots.txt єдиний, де слайд і документація збігаються щодо типового часу, 24 години, хоча документація додає, що Google може довше тримати кешовану копію, якщо оновлення не вдається. Якщо ви розблокували щось важливе, звіт robots.txt дає змогу попросити Google знову завантажити файл, але, як застерігає Google, це «не гарантує негайного повторного сканування розблокованих URL-адрес».

Про ліміт швидкості сканування варто пам’ятати перед розпродажем або зміною хостингу. За даними ROAST, він може впасти за секунди, коли Google відступає, а слайд оцінює відновлення в один-три тижні. Посібник Google про бюджет сканування називає причину: коли сайт сповільнюється або відповідає помилками 5xx чи 429, «ліміт знижується, і Google сканує менше». Першого дня того самого заходу спікери Google назвали дедалі більшими проблемами CDN, що блокують Googlebot, і сторінки перевірки на бота (challenge pages), які повертають 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 дні, щоб досягти органічного трафіку старого. Дослідження спиралося на сторонні оцінки трафіку й вибірку, зібрану краудсорсингом, тож його середнє більше говорить про ризик, ніж про будь-який окремий сайт.

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

Скільки минає часу, доки зміни з’являться у видачі?

За цифрами слайда новий заголовок чи сніпет типово з’являється за один-два дні, а заходи, вжиті вручну, знімають через один-два тижні після запиту на повторний розгляд. Найповільніше йде відновлення після основного оновлення (core update). Типово це від трьох до шести місяців, а в найгіршому випадку сайт чекає наступного core update.

Найшвидший важіль у списку дає інструмент видалення, і тут довідкова сторінка Google збігається зі слайдом. Він приховує URL-адресу з результатів приблизно на шість місяців, і Google зазначає, що блокування URL-адреси не зупиняє сканування сторінки. Для постійного видалення все одно потрібна зміна на самій сторінці, і тоді діє повільніший годинник індексування.

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

Щодо заходів, вжитих вручну, слайд додає те, чого документація не згадує: неактивні сайти чекають значно довше. Сама довідкова сторінка каже, що розгляд, пов’язаний із посиланнями, може тривати довше, ніж зазвичай, і просить не надсилати новий запит, поки ви не отримали рішення щодо попереднього.

Скільки триває розгортання core update і spam update?

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

Чотири з дев’яти core update вклалися в два-чотири тижні. З чотирьох spam update 2026 року два були близькі до одного-двох днів, які наводить ROAST: березневе тривало 19,5 години, а червневе дві доби. Серпневе тривало 2 дні 16 годин, а вересневе розгорталося 13 днів 16 годин; Gary виступав через вісім днів після його початку, як зазначив PPC Land. Власні примітки Google до запуску на дашборді обережні: «може тривати до 2 тижнів», «до 3 тижнів», «до місяця».

База знань читає той самий рядок слайда інакше: core update впливає на сайт протягом двох-чотирьох тижнів від початку розгортання, а spam update протягом одного-двох днів. За такого прочитання слайд описує, коли сайт відчуває зміну, а наведені вище тривалості з дашборда цьому не суперечать. Ми перевірили формулювання ROAST, бо саме воно поширилося.

Для власного аналізу найкорисніша цифра, яку опублікував Google, досі та, що стоїть на його сторінці про core update: зачекайте «щонайменше цілий тиждень після завершення 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 How Search Works про спам досі її використовує, а новішого підрахунку ми не знайшли. Його застереження, що масовий контент тепер більша проблема, ніж спам із посиланнями, не підкріплене опублікованими даними, тож це оцінка зсередини команди.

Він також сказав, що core update працюють на рівні сторінки, а не домену, тому одні сторінки сайту зростають, а інші падають. Посібник Google із систем ранжування каже, що його системи «розроблено для роботи на рівні сторінки», а далі додає: «Також використовуються сигнали й класифікатори рівня всього сайту». Отже, кожну сторінку оцінюють окремо, з урахуванням того, що Google думає про сайт навколо неї.

Де слайд і документація Google розходяться

У більшості рядків слайд просто точніший за документацію, яка не дає жодної цифри. У кількох місцях вони вказують у різні боки, тож перш ніж цитувати цифру клієнту чи керівникові, варто знати, звідки вона:

• Індексування: приблизно 1,5 години на слайді, «приблизно день» і «до тижня чи двох» на довідкових сторінках.
• Переїзди сайтів: на слайді типово від одного до трьох місяців, у посібнику «кілька тижнів» для малих і середніх сайтів.
• noindex та інші мета-анотації: щонайбільше чотири дні на слайді; документація застерігає, що повторний візит «може тривати місяці». Обидва твердження можуть бути правдивими, якщо слайд рахує від повторного сканування.
• Розгортання, як слайд читає ROAST: від двох до чотирьох тижнів для core update і від одного до двох днів для spam update; на дашборді від 6 до 45 днів і від 19,5 години майже до чотирьох тижнів.
• Рівень сторінки: на сцені «не на рівні домену»; у посібнику сигнали рівня сайту «також використовуються».

Записи учасників розходяться ще в одному місці: для анотацій посилань ROAST указує як найдовший час «місяці», тоді як база знань читає кінцеву точку на слайді як приблизно один рік.

Так ми пояснюємо цю різницю: документацію пишуть так, щоб вона була безпечною для будь-якого сайту, і переглядають рідко, а слайд показує виміряні середні значення для всього вебу. Жодне з двох не є обіцянкою для вашого сайту.

Що ще Google сказав третього дня

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

John Mueller почав із розуміння запиту. Google визначає мову, відкидає стоп-слова, якщо вони не належать до назви, розпізнає сутності й розширює синоніми, тож «fried chicken place in barcelona» шукають так, ніби там було place OR area OR location OR restaurant. Деякі синоніми залежать від контексту: GM означає General Motors поряд із «car» і genetically modified поряд із «barley». Споріднені терміни (siblings), як-от Canon і Nikon, Google вивчає з пошукових запитів людей у форматі «X vs Y» і не змішує їх. How Search Works згадує «досконалу систему синонімів», але споріднених термінів і переписування за схемою OR немає в жодному документі, який ми знайшли. Для AI Overviews і AI Mode модель додає query fan-out (розгалуження запиту на кілька пов’язаних пошуків), який сторінка Google про функції AI описує як «виконання кількох пов’язаних пошуків за підтемами й джерелами даних». Mueller сказав, що Search Console не показує запити fan-out, бо вони не надходять від користувачів. Потім Gary пояснив відбір кандидатів (retrieval): перед ранжуванням 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 року, спершу для обмеженого кола сайтів) і мультимодальна звітність для вебу (24 вересня 2026 року). ROAST пише, що оновлення щодо звітності про генеративний AI не було. Це означає, що нічого нового не анонсували: звіт про ефективність генеративного AI існує з 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 Search використовують ті самі процеси, що й традиційні результати. Посібник 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; день 1, 30 вересня 2026 року: weareroast.com; день 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