Поддержка Проблемы и решения При обращении к странице роботу не удалось получить её содержимое

  • Доброго света всем!
    Есть сайт на WordPress, и у него сейчас очень серьезная проблема! Это в ЯндексВебмастере случалось и ранее, но последнее время просто наводнение какое то! Каждый день страницы выпадают из индекса по причине

    «Не удалось скачать страницу. при обращении к странице роботу не удалось получить её содержимое. Проверьте ответ сервера и отсутствие запрещающих HTML-тегов.»
    код страницы: N / a (Документ не содержит текст)

    Проверяю — все 200 ОК! Отправляю странички на переобход — бот обходит, возвращает в индекс! На завтра — другие выпадают по этой ошибке!
    Стукнул платонам, ответили

    Ситуация связана с тем, что ранее данные страницы отвечали на запросы робота следующим сообщением:
    <html><body><script>document.cookie=»bpc=b2d2efec1bb89dc4bb3a5a77d31eb1c6;Path=/»;document.location.href=»https://site.ru/novosty/?attempt=1«;</script></body></html>

    Так как в контенте страниц не было никакого текстового содержимого, которое робот мог бы загрузить в результаты поиска, страницы были исключены из выдачи. Для выяснения причин появления проблемы вы можете обратиться к администратору сервера, на котором расположен сайт, либо вашему хостинг-провайдеру. Проблема возникала, например, при обращении робота к странице https://site.ru/novosty/ 2019-03-07 в 17:53:29. Чтобы страницы могли корректно индексироваться, рекомендуем убедиться, что они постоянно доступны и отдают актуальный контент.

    Если страницы будут недоступны из поиска, то они действительно будут исключаться из выдачи, какой-либо ошибки в этом нет. В случае кратковременной недоступности страниц мы рекомендуем настраивать http-код ответа 503 со страниц. Именно такой код ответа может помочь избежать исключения ссылок, если они будут недоступны недолгое время.

    Хорошо, иду к хостеру, спрашиваю, мол что за дела — спрашиваю раз, спрашиваю два — хостер твердит одно и то же

    На тот момент для Вашего сайта была включена фильтрация на уровне сервера из-за атаки Ваш сайт. Сейчас фильтрации уже нет.

    Мой сайт — что?! — каждый день атакуют?
    Но важно тут то, что 1 марта делал попытку перейти на https — но все закончилось обломом — часть сайта поломалась, вернее именно посты и статич.страницы были недоступны, потому что браузеры выдавали такое

    «На этой странице обнаружена циклическая переадресация» или ERR_TOO_MANY_REDIRECTS
    Это сообщение означает, что зафиксировано слишком много попыток перенаправить вас на другой адрес.
    Ошибка может быть связана с файлами cookie. Чтобы устранить проблему, удалите их.

    Вот! Поэтому я вернул все обратно (т.е. сейчас сайт снова на http) — но именно после этого отката и началась эта котовасия, ежедневная канитель!
    Еще заметил, что iThemes Security перестал с этого времени собирать логи об апдейтах движка и плагинов, хотя другие логи (404 и пр.) все исправно печатаются.

    А САМОЕ ГЛАВНОЕ — почему то я не вижу таких ошибок в Вебмастере Google, равно как ни разу не видел в нем ошибки «Долгий ответ сервера. При обращении к страницам сайта среднее время ответа сервера превышает 3 секунды.», которая тоже время от времени появляется в ЯндексВебмастере.

    Подскажите пожалуйста, с чем это может быть связано, хотя бы примерные какие догадки — очень буду благодарен за подсказку!)))

Просмотр 13 ответов — с 1 по 13 (всего 13)
  • рекомендую менять хостера.
    если хостеры втихую включают «фильтрацию» и теми самым посылают далеко и надолго поисковых ботов — самое время бежать от них со всех ног.

    Flector
    Вас я услышал. Но мне встречалось и такое мнение

    Как вариант, проблема возникает именно из-за Яндекса, то есть, приходит его робот и устраивает мини DDoS

    С ботами гугла, судя по всему, проблемы то нет.

    С ботами гугла, судя по всему, проблемы то нет.

    боты гугла могут просто индексировать неполноценную страницу.

    Flector

    боты гугла могут просто индексировать неполноценную страницу.

    Смотрел в Посмотреть как Гуглбот (последние дни, кстати, доживает сей инструмент) — непонятно. То если в Сканировать выводит html страницы, то вроде нет полезного текстового контента, то он есть. Если же в Сканировать и отобразить — то все на месте.

    так вот значит еще стал я гуглить, что это

    <html><body><script>document.cookie=»bpc=b2d2efec1bb89dc4bb3a5a77d31eb1c6;Path=/»;document.location.href=»https://estellemoda.ru/novosty-mody/modnye-trendy/modnye-tendencii-osen-zima-2016-2017/?attempt=1&#8243;;</script></body></html>

    означает, что на сервере для защиты от ДОС используются testcookie — при которых якобы доступ будет осложнен не только для атакующих ботов, но и для поисковых. В общем спросил я снова хостера, ответили

    Да, Когда включена фильтрация, идет проверка соединения по специальной куке.
    Но
    У нас для поисковых ботов включено исключение по их IP-адресам, и они не испытывают проблем с доступом.

    Я мол, а что ж тогда яндексботы достучаться не могут? А они говорят

    Возможно у поисковых ботов Яндекса сменились IP-адреса.

    Я им: а что, у яндексов каждый день меняются IP-адреса?
    Они

    У Вас в файле .htaccess сайта указаны IP-адреса для запрета им доступа к сайту. Это действия плагина iThemes Security , он автоматически может добавлять IP-адреса и удалять их из списка заблокированных.

    Ага! Помню, что этот плагин вроде как ранее блочил яндексов по юзерагенту, а что по айпишникам может — упустил из виду. В общем выключил я в плагине этот раздел — прошло несколько дней, нет, зараза, все равно та же ошибка в Янвебмастере!
    Я еще тогда хостера спросил, помню — ваша фильтрация все же основана на testcookie или нет? Ответ меня несколько удивил: )))

    Судя по отдаваемому адресу, то да.

    В общем я не программист, конечно, и не знаю кому верить — то ли статьям про тесткуки, то ли хостеру, который уверяет, что для яндексботов фильтра нет.

    • Ответ изменён 8 месяцев, 3 недели назад пользователем StellaStan.
    Модератор Yui

    (@fierevere)

    ゆい

    Yui

    https://webmaster.yandex.ru/tools/server-response/
    проверяли через это?

    Да, я все время. Чаще всего 200. Но бывает, что выдает «Не удалось скачать содержимое страницы» — но если через сек-другую перепроверить, то все ОК. Спросил об этом Платона, он сказал

    Что же касается проверки ответа сервера, если периодически появляется статус «Не удалось скачать содержимое страницы», как правило, это может быть связано с тем, что при запросах данного инструмента страница отвечает с задержками, из-за чего соединение прерывается по тайм-ауту. Возможно также, что запросы с некоторых IP-адресов инструмента блокируются при попытке посетить страницу.

    И да

    также см. https://yandex.ru/support/webmaster/robot-workings/check-yandex-robots.html

    в том же тикете Платон сослася на это тоже

    Замечу, что наши роботы используют очень большое число IP-адресов, и они могут меняться. К тому же разные сервисы Яндекса могут использовать разные IP. В связи с этим мы рекомендуем определять роботов не по IP-адресу, а по User-Agent и/или обратному DNS-запросу. Подробнее о том, как проверить, что робот принадлежит Яндексу, вы можете узнать в нашем разделе Помощи: https://yandex.ru/support/webmaster/robot-workings/check-yandex-robots.html .

    В общем, это что выходит: хостер просто тупо юзает тесткуки — или же не тупо, но что то там не донастраивает?

    • Ответ изменён 8 месяцев, 3 недели назад пользователем StellaStan.

    В общем, это что выходит: хостер просто тупо юзает тесткуки — или же не тупо, но что то там не донастраивает?

    Деактивировать все плагины защиты. Посмотреть. Забекапить .htacess и вычистить все запреты для ip. Если ничего не поменялось, отправляйте хостера в пешее эротическое, а сами отправляйтесь к нормальному.
    Теперь варианты:
    Скорее всего они устанавливают js-редирект для защиты от DDOS, при этом, ботов яндекса защита благополучно определяет как дудосеров. Соответственно они топают на пустую страничку, которая не подтягивает sql-запросы и весит пару килобайт. Есть еще вариант, что они отсеивают подозрительные запросы через nginx и блокируют. Но судя по содержанию ошибки, бот попадает на пустышку. Короче, скорее всего проблема в хостере.

    1 марта делал попытку перейти на https — но все закончилось обломом — часть сайта поломалась

    Надо линки поменять. Делал с помощью этого плагина:
    https://ru.wordpress.org/plugins/really-simple-ssl/
    И потом поработать с БД вот этим плагином, чтобы линки в статьях и прочих местах были заменены:
    https://ru.wordpress.org/plugins/better-search-replace/

    ren334

    Скорее всего они устанавливают js-редирект для защиты от DDOS, при этом, ботов яндекса защита благополучно определяет как дудосеров.

    То есть это модуль testcookie вообще по определению такой, или все же его умелыми руками можно грамотно настроить?

    скорее всего проблема в хостере…

    Наверное на другой тариф этого же хостера бессмысленно переходить? (например на базовый VPS) — потому что и там эта блокировка будет активна?

    Надо линки поменять. Делал с помощью этого плагина:
    https://ru.wordpress.org/plugins/really-simple-ssl/
    И потом поработать с БД вот этим плагином, чтобы линки в статьях и прочих местах были заменены:
    https://ru.wordpress.org/plugins/better-search-replace/

    Именно в такой последовательности плагины применять?

    Я менял протокол через Notepad++ методом замены — но что то криво вышло: главная, страницы разделов и тегов нормально открывались в https, а вот посты и статич.страницы выдавали циклический редирект.
    Я потом возращал бэкап базы обратно и затем уже менял через sql-запросы — нет, все равно эта циклическая переадресация выходила.((

    (например на базовый VPS)

    На большинстве хостингов VPS/VDS/DS выдается без технического администрирования, всё можно/нужно настраивать самостоятельно. Если у Вас нет навыков системного администратора (не путать с офисным эникейщком), то придется привлекать стороннего специалиста, а это стоит Денег. Зато можно почти всё сделать по собственному усмотрению, включая защиту от DDoS.

    Юрий

    На большинстве хостингов VPS/VDS/DS выдается без технического администрирования, всё можно/нужно настраивать самостоятельно.

    Это понимаю. Не о том немного речь. А вопрос в том, что «Наверное на другой тариф этого же хостера бессмысленно переходить? — потому что и там эта блокировка будет активна?». Не один ли, который редьки не слаще, потому что хостер один и вытворяет на всех тарифах одинаково — или нет?

    Вот это тоже кстати в Янвебмастере частенько «Долгий ответ сервера. При обращении к страницам сайта среднее время ответа сервера превышает 3 секунды.» А ведь по тарифу подключен гугловский Pagespeed — а толку, выходит, никакого!

    Еще вот увидел в Вебмастере пару ошибок связанных с этим /?attempt=1 в этих критичных урлах

    Индексирование страницы запрещено в файле robots.txt.

    По причине директивы Disallow: /*?*
    Вот уж не думал, не гадал.
    Но ведь большинство все же по причине (Документ не содержит текст) выпадает — так что роботс тут вроде не при чем?

    Вчера отключил iThemes Security совсем. Сегодня фатал ошибка — главная выпала, не содержит текст! Случилось наконец! )))(((

    По причине директивы Disallow: /*?*

    Советую убрать. По крайней мере, для Гугли. У неё случается истерика, если ей запрещают индексировать стили и скрипты, а они в вордпрессе подключаются с версией (типа style.css?ver=20190311).

    так что роботс тут вроде не при чем?

    Абсолютно.

Просмотр 13 ответов — с 1 по 13 (всего 13)
  • Тема «При обращении к странице роботу не удалось получить её содержимое» закрыта для новых ответов.