Почему Googlebot сканирует страницы /mobile/ * и/m/*, на которые не ссылаются нигде?

С конца мая у меня появилось много новых ошибок 404 на странице "Ошибки сканирования смартфонов" в консоли Google для веб-мастеров/Google. Все они начинаются с/m/или/mobile/, ни одна из которых не существует и не связана нигде на сайте.

Например, у меня есть ошибка 404 для http://www.example.com/mobile/foo-bar/ и http://www.example.com/m/foo-bar. Согласно Search Console, эта страница связана на существующей странице http://www.example.com/foo-bar/, но это не так.

Является ли Googlebot самостоятельно решать мобильную версию каждой страницы? Могу ли я отключить это поведение? Это потому, что мой сайт еще не является мобильным (проблема, за которую я получил другое предупреждение от Google).

Ответ 1

Как упоминается в комментарии @Jonny 5, это, похоже, происходит в результате того, что Google предположил, что у вас может быть мобильная версия вашего сайта в каталогах /m и/или /mobile. Из того, что я прочитал, они будут проверять эти каталоги только в том случае, если они решили, что страницы, которые они первоначально индексировали, не были мобильны/отзывчивы. Более подробную информацию об этом поведении можно найти в этих разделах Форума Google Product:

Еще один полезный комментарий пришел от пользователя @user29671, который указал, что на вашем сайте действительно есть URL-адреса с индексированными /m и /mobile. Я обнаружил, что то же самое верно для моего веб-сайта, поэтому это поведение также может быть ограничено сайтами, которые Google (по какой-либо причине) индексировал URL /m и/или /mobile. Чтобы проверить, верно ли это для вашего сайта, перейдите по следующим URL-адресам и замените example.com на свой сайт:

Что касается предотвращения этого, лучше всего создать мобильную версию вашего сайта или перенаправить страницы /m и /mobile обратно на оригиналы.

Ответ 2

Вы можете заблокировать эти каталоги в своем файле robots.txt, но это немного обходное решение. Лучшим вариантом было бы выяснить, откуда именно Googlebot собирает эти URL-адреса.

Если вы поделились URL-адресом страницы примера, где Google говорит, что у вас есть ссылки на/мобильные страницы, я мог бы посмотреть на нее и выяснить, где это происходит.

И нет, Google не просто изобретает каталоги для сканирования по независящим от вас случайным образом, что вы случайно набрали мобильную страницу:)

Ответ 3

У меня такая же проблема с декабря 2016 года. Googlebot постоянно пытается обходить страницы моего сайта с помощью префиксов/m/и/mobile/.

Все эти URL-адреса вызывают ошибки 404 и отображаются в Инструментах Google для веб-мастеров как ошибки.

Автоматическая электронная почта была получена от GWT 2 января 2017 года, указав

Googlebot для смартфонов определил значительное увеличение количества URL-адресов на http://example.com, которые возвращают ошибку 404 (не найдена). Если эти страницы существуют на вашем рабочем столе, сообщение об ошибке для мобильных пользователей может быть плохим пользовательским интерфейсом. Эта неправильная конфигурация также может помешать Google показывать правильную страницу в результатах мобильного поиска. Если эти URL-адреса не существуют, никаких действий не требуется.

Это выполняется с помощью мобильного искателя:

* Ip: 66.249.65.124

Агент: Mozilla/5.0 (Linux, Android 6.0.1, Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, например, Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (совместимый с Googlebot/2.1)

Браузер: Mozilla/5.0 (Linux, Android 6.0.1, Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, например, Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (совместимый с Googlebot/2.1) *

Таким образом, вы не одиноки. Не принимайте это близко к сердцу. Это ошибка Google:)

Ответ 4

Что касается перенаправления /m и /mobile страниц назад на оригиналы, здесь приведен фрагмент для nginx:

location /m/ {
     rewrite ^/[^/]+(/.*)$ $1 permanent;
}

location /mobile/ {
    rewrite ^/[^/]+(/.*)$ $1 permanent;
}

Можно также перенаправить все в корень:

location /m/ {
    return 301 $scheme://$host/;
}

location /mobile/ {
    return 301 $scheme://$host/;
}