Сайт відкривається у браузері, статті на місці, сервер відповідає без помилок — а Google вважає ваші сторінки дублікатами чужих. Таке може статися, якщо захист від ботів показує пошуковому роботу перевірку «Я не робот» замість справжнього контенту.
CAPTCHA та індексація Google конфліктують тоді, коли перевірка перекриває Googlebot доступ до сторінки. Особливо підступний випадок — екран перевірки з відповіддю HTTP 200 OK: запит формально успішний, але робот отримав зовсім інший документ.
Цей сценарій Джон Мюллер із Google пояснив у випуску Search Off the Record про звіт індексування від 16 липня 2026 року. Йдеться про наслідки роботи захисної інфраструктури, які легко пропустити під час звичайної перевірки сайту.
Як CAPTCHA перетворює різні сторінки на дублікати
Уявімо, що Googlebot запитує статтю з унікальним текстом. CDN, хостинг або система фільтрації трафіку оцінює запит як підозрілий і повертає стандартну сторінку перевірки. Для людини на цьому місці був би додатковий крок перед відкриттям матеріалу. Для пошукового робота це може виявитися єдиним доступним вмістом URL.
Однакові екрани перевірки використовують різні сайти. Якщо Google отримує їх замість статей, він бачить схожі документи й може об’єднати їх як дублікати. Далі пошукова система обирає канонічну версію — адресу, яку вважає основною в цій групі.
Такою адресою іноді стає сторінка іншого домену з тим самим екраном перевірки. Ваш URL тоді може втратити самостійну індексацію. Унікальність тексту не рятує, якщо Googlebot цього тексту взагалі не отримав.
Це можливий наслідок підміни вмісту, а не автоматична санкція за CAPTCHA. Наявність перевірки на сайті сама по собі ще не означає проблеми з пошуком.
Чому браузер і поточний тест можуть не показати проблему
Власник сайту заходить зі свого IP, переглядає кілька сторінок і бачить нормальний контент. Googlebot надсилає запити з інших адрес і може сканувати інтенсивніше. Саме за таких умов захист іноді починає вимагати перевірку, хоча звичайним відвідувачам нічого не заважає.
Я б почав діагностику з кількох проблемних URL у Google Search Console. Перегляньте статус індексування, дату останнього сканування та порівняйте канонічну адресу, заявлену сайтом, з адресою, яку обрав Google. Якщо друга веде на сторонній домен, варто з’ясувати, що саме робот отримав.
У інструменті перевірки URL можна переглянути повернутий HTML, якщо ці дані доступні. Шукайте в ньому текст перевірки, повідомлення про обмеження або іншу заглушку замість статті.
Поточний тест URL допомагає перевірити доступ зараз, але використовує Google-InspectionTool. Його успішний результат не доводить, що звичайний Googlebot завжди отримує той самий вміст. Крім того, поточний тест не прогнозує вибір canonical: ця інформація є в даних з індексу.
Чужа канонічна адреса — привід для перевірки, а не готовий діагноз. Помилкові теги canonical, перенаправлення та дублювання контенту також потребують уваги. CAPTCHA варто розглядати поряд з іншими причинами втрати видимості в Google.
Що виправляти в захисті та як перевірити результат
Наступний крок — журнали CDN, хостингу та системи захисту. Зіставте час сканування проблемних URL із запитами до них, IP-адресами, кодами відповіді та правилами, які спрацювали. Самого запису «200 OK» замало: потрібно встановити, чи повернула система статтю, чи екран перевірки.
Якщо обмеження створює сторонній сервіс, передайте його підтримці конкретні URL та час запитів. Так простіше знайти правило, що помилково зачіпає пошукового робота, ніж вимикати захист навмання.
Винятки слід налаштовувати для підтверджених роботів. Назви Googlebot у User-Agent недостатньо — її можна підробити. Google описує перевірку запитів своїх роботів через опубліковані діапазони IP або зворотний DNS-запит із подальшою прямою перевіркою адреси. Якщо сервіс має механізм розпізнавання перевірених ботів, з’ясуйте, чи він увімкнений і як застосовується до ваших правил.
Після зміни налаштувань перевірте доступ до справжнього контенту та наступні звернення Googlebot у журналах. Самою зміною тега canonical підміну сторінки не усунути. Контроль захисних правил варто включити до технічного SEO-аудиту, особливо після зміни CDN або хостингу.
Для окремого URL можна надіслати запит на індексування. Якщо у звіті для відповідної проблеми доступна функція «Перевірити виправлення», скористайтеся нею для перевірки усунених помилок. Це різні дії, і жодна не гарантує негайного повернення сторінки в пошук.
Далі стежте за новими скануваннями та канонічними адресами у Search Console. Потрібно підтвердити дві речі: Google знову отримує ваш матеріал і більше не об’єднує його з чужою сторінкою перевірки.