Як додати сайт у Google і прискорити індексацію

Сайт зібрано, домен куплено, контент на місці, а в пошуку порожньо. Далі власник зазвичай читає гайд, у якому написано «новий сайт індексується протягом одного тижня», чекає тиждень, нічого не отримує і йде шукати винних.

Тільки того тижня немає в жодному документі Google. Компанія прямо пише, що не гарантує сканування, індексування чи показ сторінки — навіть якщо сайт повністю відповідає її вимогам. Строк, який ви десь прочитали, придумав не Google.

Чесна відповідь на питання, як додати сайт у пошукову систему Google, лежить у першоджерелах. Там є конкретні цифри, і там же видно, які популярні поради не працюють уже роками.

Тиждень на індексацію нового сайту — цифра, якої немає в документації

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

Перша — про сканування. Робот має спершу завантажити сторінку, і Google каже, що це «може зайняти від кількох днів до кількох тижнів». Друга — про індексацію вже просканованої сторінки. Довідка Search Console формулює її так: «індексація зазвичай займає близько доби, але в деяких випадках значно довше».

Складати ці два числа в одне «сайт буде в пошуку через тиждень» не можна. Сканування й індексація — окремі етапи, між ними немає фіксованої відстані, і жоден із них Google не зобовʼязується виконати. Про відсутність гарантій там написано наскрізно: і в описі роботи пошуку, і в інструкції про повторне сканування, де сказано прямо — запит на сканування не гарантує потрапляння в результати ані миттєво, ані взагалі.

Плануйте запуск так, ніби органіка зʼявиться через місяць-два, а не через тиждень. Якщо трафік потрібен на старті, це задача налаштування контекстної реклами, а не індексації.

Що насправді означає «додати сайт у Google»

Формально додавати сайт нікуди не треба. Google знаходить сторінки сам: переходить за посиланнями з уже відомих йому сайтів і завантажує текст, зображення й відео автоматичними програмами-сканерами. Каталогу, у який подають заявку, не існує з нульових.

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

1. Відкрити роботові доступ — щоб сайт не був закритий у robots.txt і не віддавав noindex на кожній сторінці.
2. Показати список сторінок — картою сайту.
3. Отримати зворотний звʼязок — підключити Search Console, щоб бачити, що Google з цим усім зробив.

Третій пункт індексацію не прискорює, але без нього ви працюєте наосліп. Решта інструментів — це варіації тих самих трьох дій.

Search Console — «Домен» чи «Префікс URL», і чому це не однаково

Перший вибір при додаванні сайту — тип ресурсу. Саме на ньому найчастіше й застрягають.

Ресурс типу «Домен» охоплює всі субдомени й обидва протоколи одразу. Підтвердити його можна тільки DNS-записом у реєстратора: способи з HTML-файлом і метатегом для доменного ресурсу не працюють взагалі. Це не помилка інтерфейсу, так задумано.

Ресурс з префіксом URL включає лише адреси, що починаються з цього префікса. Тобто https://site.com/ і http://site.com/ — два різні ресурси, і дані вони збиратимуть окремо. Зате підтвердити такий ресурс можна файлом, метатегом, через Google Analytics або Tag Manager.

Що з цього брати. Є доступ до DNS — беріть «Домен», він позбавляє від зоопарку ресурсів. Немає доступу — беріть префікс із тим протоколом і хостом, які реально працюють після редиректів.

Дрібниця, про яку мало хто знає: дані для ресурсу починають збиратись одразу після додавання, ще до підтвердження права власності. Тобто зволікання з DNS-записом статистики вас не позбавляє, ви просто її поки не бачите. Окремо існують ще й ресурси для соцмереж, про них ми писали в матеріалі про platform properties у Search Console.

Карта сайту — ліміти, lastmod і мертвий ping

Карта сайту — це спосіб показати Google список URL, коли їх багато. Для окремих адрес Google рекомендує інструмент перевірки URL, для великої кількості — саме sitemap.

Що варто знати до того, як генерувати файл:

• Один файл — максимум 50 МБ у нестисненому вигляді або 50 000 URL. Більше — ділити на кілька файлів і збирати індексом карт.
• Кодування тільки UTF-8, адреси абсолютні.
• lastmod має значення. Google підтвердив, що використовує його як сигнал для планування повторного сканування вже відомих URL. Але тільки якщо дата чесна: поставити «сьогодні» всім сторінкам одразу — швидкий спосіб знецінити сигнал.
• Звіт «Файли Sitemap» показує максимум 1000 надісланих карт. Надіслати можна більше, побачити ні.

І окрема пастка зі старих інструкцій. Багато гайдів досі радять «пінганути Google після оновлення карти» HTTP-запитом на спеціальний ендпойнт. Цей ендпойнт мертвий. Google оголосив про його відключення в червні 2023 року, тепер запити туди повертають 404, а причину назвав відверто: переважна більшість неавтентифікованих надсилань виявилась спамом. Лишилось два робочі способи — рядок Sitemap: у robots.txt (їх можна вказувати скільки завгодно, і вони не привʼязані до user-agent) і надсилання через Search Console.

Ще одна деталь, яка тверезить. Google називає надсилання карти сайту підказкою, а не гарантією. Сам файл буде завантажено швидко, але сканування перелічених у ньому URL займає час, і проскановані будуть не всі — це залежить від розміру сайту, його активності й трафіку. Карта сайту нічого Google не змушує, вона лише повідомляє.

Запит на переіндексацію і квота, числа якої ніхто не знає

Для окремої сторінки працює інструмент перевірки URL у Search Console. Він показує стан проіндексованої Google версії сторінки і дозволяє перевірити, чи URL взагалі може бути проіндексований. Це найшвидший спосіб зрозуміти, проблема в самій сторінці чи в черзі.

Далі — «Запит на індексування». І тут два факти, які варто прийняти одразу.

Перший: квота існує, але Google її числа не публікує. У документації сказано, що квота на надсилання окремих URL є; у довідці Search Console — що для кожного ресурсу діє добовий ліміт перевірок. Конкретних цифр немає ніде. Популярні в мережі «10 URL на добу» чи «50 URL на добу» — це фольклор, який кочує з блогу в блог. Не плануйте роботу навколо чужих здогадок.

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

Якщо сторінка не індексується тижнями, справа зазвичай не в кнопці, а в якості або технічному стані сторінки. Що саме перевіряти, розписано в матеріалі про SEO-аудит сайтів.

Indexing API не проіндексує вашу сторінку

Приблизно тут у чужих гайдах зʼявляється порада «використайте Indexing API, і сторінка буде в індексі за годину». Це неправда, і спростовує її одне речення документації.

Indexing API можна застосовувати лише до сторінок із розміткою JobPosting або BroadcastEvent усередині VideoObject. Тобто вакансії й прямі трансляції. Звичайна стаття блогу, картка товару, сторінка послуги під цей API не підпадають, і надсилати їх туди марно.

Цифри 200 publish-запитів на добу і 380 запитів за хвилину, які іноді цитують як «ліміти індексації в Google», стосуються саме цього API, а не Search Console. Google додає, що квота може як зростати, так і зменшуватись залежно від якості документів, а спроби її обійти, зокрема кількома акаунтами, караються відкликанням доступу. Усі надсилання проходять перевірку на спам.

Якщо у вас не сайт вакансій і не трансляції, забудьте про цей інструмент.

IndexNow — корисний протокол, який до Google не має стосунку

IndexNow повідомляє пошуковим системам про зміну сторінки одним запитом: до 10 000 URL за раз, з ключем із 8–128 шістнадцяткових символів, який лежить у корені домену й підтверджує ваше право на нього. URL, надіслані одній системі, автоматично передаються всім іншим учасникам протоколу.

Учасники за FAQ самого протоколу — Amazon, Bing, Naver, Seznam.cz, Yandex і Yep. Google у цьому списку немає. Тому будь-яка порада «увімкніть IndexNow, щоб прискорити індексацію в Google» помилкова за визначенням.

Протокол від цього не стає непотрібним. Для українського бізнесу Bing — це ще й трафік із Copilot, а сам IndexNow чесно попереджає, що миттєвої індексації не гарантує, лише підвищує ймовірність швидшого виявлення змін. Просто рахуйте його як роботу з іншими системами, а не з Google. До речі, з видимістю в AI-відповідях повʼязана окрема дисципліна, GEO-оптимізація, і вона теж не про Search Console.

Окремо: добової квоти на надсилання URL у Bing ми не називаємо, бо офіційна довідка з цим числом зараз недоступна. Побачите таку цифру в чужій статті — спитайте джерело.

robots.txt і головна помилка, через яку сторінки зникають

Файл robots.txt має лежати в кореневому каталозі, і його правила діють тільки для того хоста, протоколу й порту, де він розміщений. Robots.txt на http://site.com не керує роботом на https://site.com.

Три речі, про які майже ніхто не пише:

• Ліміт 500 KiB. Усе, що після нього, Google просто ігнорує.
• Кеш до доби. Зміни в robots.txt діють не миттєво: Google зазвичай тримає вміст файлу до 24 годин, а іноді довше.
• Robots.txt не ховає сторінку з пошуку. Він керує доступом сканерів до URL, і Google прямо пише, що це не механізм приховування. Закрита в robots.txt сторінка все одно може потрапити в індекс, якщо на неї посилаються інші сайти.

А тепер найдорожча помилка, якої немає в жодному з топових гайдів.

Noindex під Disallow не спрацює. Логіка здається бездоганною: закриваємо сторінку в robots.txt і ставимо на неї метатег noindex, подвійний захист. Насправді виходить нуль захисту. Щоб noindex подіяв, сторінка не має бути заблокована в robots.txt і має лишатись доступною для сканера. Інакше робот ніколи не побачить директиву, і сторінка може далі показуватись у результатах. Це записано в документації Google про noindex буквально.

Працює це так: щойно Googlebot просканує сторінку і витягне тег або заголовок, Google прибирає її з пошуку повністю, незалежно від того, скільки сайтів на неї посилаються. Але для цього йому треба дати її прочитати.

Дзеркальна версія тієї самої помилки нищить нові сайти. Стейджинг закрили від індексації, сайт переїхав у продакшн, Disallow: / або noindex у шаблоні лишились. Сайт живий, гарний, швидкий — і невидимий. Перше, що варто відкрити після релізу, — це site.com/robots.txt і код головної сторінки.

Порядок дій після запуску сайту

Що ми робимо на кожному релізі, у цій послідовності:

1. Перевіряємо robots.txt і метатеги. Немає Disallow: /, немає noindex у шаблоні. На виході — сайт відкритий для сканування.
2. Додаємо ресурс у Search Console. Тип «Домен», якщо є доступ до DNS. На виході — підтверджені права й початок збору даних.
3. Генеруємо карту сайту й вказуємо її в robots.txt. UTF-8, абсолютні URL, чесний lastmod, поділ на файли, якщо URL більше за 50 000. На виході — Google має повний список сторінок.
4. Надсилаємо карту через Search Console і перевіряємо звіт на помилки. На виході — карта прочитана.
5. Просимо просканувати ключові сторінки через інструмент перевірки URL. По одному разу, без фанатизму.
6. Чекаємо і дивимось звіти. Не кнопку натискаємо, а читаємо причини виключення сторінок з індексу.

Швидкість завантаження на цьому етапі теж важить: повільний сайт сканується гірше, а як це виправити, ми розбирали в матеріалі про швидкість сайту. А коли сторінки в індексі вже є, а позицій немає, починається інша робота — пошукова оптимізація і докази експертності, про які ми писали в матеріалі про E-E-A-T.

FAQ