Amazon и Google: почему HTTP 200 всё ещё может означать провал

HTTP 200 от Amazon или Google не доказывает, что сбор данных (скрейпинг) сработал. Оба сайта могут ответить на похожий на бота запрос страницей проверки, оболочкой поиска, которую должен заполнить JavaScript, или полной страницей разметки, в которой всё равно нет записей, нужных парсеру, — и все три приходят со статусом 200. Эта статья описывает такие шаблоны ответов, объясняет, почему один лишь статус — плохая проверка успеха, и перечисляет правила и официальные интерфейсы, которые стоит изучить до любого сбора. Она не приводит измерений ни одного из сайтов и не устанавливает, как повели бы себя резидентные или мобильные прокси.

Как эти ответы выглядят на практике

Большую часть путаницы создают три класса ответов, и ни один из них не различим по коду статуса.

Страница проверки. Статус 200, тело маленькое, заголовок пустой или общий, а HTML состоит в основном из JavaScript, который запускает интерстициальную страницу или проверку системы защиты от ботов. Разметка проверки Amazon, например, содержит функцию проверки и маркер верификации, а не содержимое магазина. Счётчик успеха только по статусу принимает такой ответ, хотя парсер не находит ничего.

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

Оболочка страницы. Статус 200, тело среднего размера, заголовок — общее название сайта, а HTML содержит скрипт, просящий браузер включить JavaScript, рядом с блоком noscript. Заголовков результатов, которые парсер мог бы сопоставить, нет. Это согласуется с разметкой, ожидающей дальнейшей обработки браузером, но не говорит, преуспел бы браузер и получил бы другой исходящий адрес ту же оболочку.

Один и тот же адрес может получать разные классы ответов на последовательные запросы к разным путям. Поэтому IP-адрес сам по себе ответ не предсказывает: свой вклад вносят путь, тайминг, заголовки, cookie и решения на стороне сервера, и ни одно из них не контролируется сменой исходящего узла.

Полезный вывод узок: строка статуса не говорит парсеру, есть ли у него нужные данные. Трактуйте 200 как «ответ пришёл», а не «сбор данных удался».

Проверяйте тело, а не статус

Проверке содержимого нужны ответы как минимум на четыре вопроса по каждому ответу.

• Соответствует ли заголовок тому, какой должна быть страница, а не пустой строке, общему названию сайта или странице верификации?
• Содержит ли тело маркер скрипта проверки или системы защиты от ботов? Если да, классифицируйте ответ как проверку независимо от статуса.
• Сколько записей разобрано и несёт ли каждая поля, нужные приложению? Записывайте число разобранных записей, а не число вхождений строки-маркера.
• Является ли HTML оболочкой, ожидающей, что её заполнит JavaScript? Блок noscript или скрипт с просьбой включить JavaScript — сильный сигнал.

Логируйте ответы рядом со статусом HTTP, кодом выхода curl и таймингом передачи. Поля --write-out в curl, такие как size_download и time_starttransfer, описаны в руководстве curl; они описывают передачу, а не результат приложения, и записывать нужно и то и другое рядом.

Robots.txt и правила сервисов

Протокол Robots Exclusion описывает инструкции для краулеров. RFC 9309 явно отделяет эти инструкции от авторизации доступа. Отсутствие правила disallow само по себе не является разрешением собирать или переиспользовать содержимое.

На момент проверки 11 сентября 2026 года robots.txt Google запрещал /search в общей группе user-agent с отдельными исключениями, включая /search/about и /search/howsearchworks. Оценивайте фактический путь и применимую группу; число правил или номер строки — не полезная проверка разрешений.

Для Amazon проверьте robots.txt и Условия использования соответствующего маркетплейса вместе с любым соглашением конкретной программы. Эта статья не устанавливает, что какой-либо путь поиска или товара разрешён для конкретного сбора или переиспользования.

Условия Google, действующие с 30 июля 2026 года, ограничивают автоматизированный доступ, нарушающий его машиночитаемые инструкции. Его политика Поиска о машинно-сгенерированном трафике отдельно охватывает автоматизированный доступ к Поиску без явного разрешения, включая сбор результатов для проверки позиций. Изучите актуальные документы для вашего сервиса и региона; смена исходящего адреса эти требования не меняет.

Официальные варианты доступа к данным

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

• Amazon Creators API предоставляет доступ к каталогу товаров издателям и партнёрам-аффилиатам в соответствии с требованиями программы. Это поддерживаемый преемник Product Advertising API 5. Уведомление о прекращении поддержки от Amazon говорит, что продолжающиеся вызовы PA-API 5 получают ответ 403 с AccessDeniedException. Начните с документации Creators API.
• Amazon Selling Partner API поддерживает авторизованные приложения, работающие с данными продавцов-партнёров, такими как листинги и заказы. Его обзор объясняет область применения; доступ зависит от приложения, разрешений и продавца-партнёра.
• Google Custom Search JSON API закрыт для новых клиентов. Существующие клиенты должны перейти на альтернативу до 1 января 2027 года. Обзор Google указывает на Vertex AI Search для до 50 доменов и на канал запроса для задач поиска по всему вебу. Эти варианты требуют отдельной проверки пригодности и доступности; устаревший API — не доступная отправная точка для нового клиента.
• Google Search Console отчитывается о поисковой эффективности вашего собственного сайта, включая клики, показы и среднюю позицию. Эти метрики могут ответить на вопросы о ваших подтверждённых ресурсах, но не дают полной ленты позиций конкурентов.

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

Когда может помочь подключение из конкретной локации

Авторизованная проверка локации может изучать, как ваш листинг выглядит на другом рынке, видна ли региональная кампания или почему покупатель видит другое содержимое. Это основания оценить подключение из соответствующего региона — с соблюдением правил сервиса.

Исходящий IP-адрес — лишь одно из входных данных такого теста. Держите браузер, язык, состояние аккаунта и настройки сессии одинаковыми и записывайте, что вы меняли. Единичный запрос или малый объём сами по себе не устанавливают разрешения, а региональный исходящий узел не воспроизводит персонализированный вид каждого покупателя.

Руководство по ротируемым и sticky-прокси объясняет выбор сессий. Сравнение резидентных и серверных прокси описывает, как оценивать пулы-кандидаты. Эта статья не измеряет ни один из типов; выбирайте между ними по авторизованному сравнению собственной нагрузки.

Что записывать в авторизованном сравнении

Определите успех на уровне приложения до отправки запросов. Для данных о товарах это может означать совпадающий идентификатор товара и все обязательные поля; для поисковых данных — разобранную структуру результатов и ожидаемый контекст запроса. Подсчёт заголовков или маркеров может быть полезной диагностикой, но не должен заменять проверку записей, которые вы будете использовать.

Записывайте точный публичный тестовый URL и запрос, метку времени в UTC, версию клиента, настройки запроса, политику редиректов, шлюз или прямой маршрут и метод проверки содержимого. Храните статусы HTTP и CONNECT, код выхода curl и тайминг вместе с результатом приложения. Сохраняйте достаточно очищенных свидетельств ответа, чтобы объяснить проверку, отсутствующие поля или изменившийся результат парсера.

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

Методика бенчмарка даёт отправную точку для транспортных измерений и объясняет, где нужны проверки, специфичные для приложения. Если CONNECT возвращает 407, разбирайтесь с аутентификацией на прокси по руководству по 407. Руководство по настройке curl показывает, как записывать статусы CONNECT и HTTP по отдельности.

Чего эта статья не устанавливает

Эта статья не сравнивает ответы через резидентные или мобильные исходящие узлы, не тестирует рендеринг в браузере, не проверяет полноту записей о товарах и не измеряет устойчивую частоту проверок. Никакое число запросов с одного адреса не может оценить долю успеха провайдера или предсказать поведение при другом объёме запросов. Используйте описанные выше шаблоны, чтобы спроектировать проверку содержимого; выбор прокси основывайте на отдельном авторизованном сравнении той нагрузки, которую вам нужно выполнять.

Теги:ProxiesChoosing proxies