Cправка — Search Console
Войти
Справка Google
- Справочный центр
- Сообщество
- Search Console
- Политика конфиденциальности
- Условия предоставления услуг
- Отправить отзыв
Тема отзыва
Информация в текущем разделе Справочного центра
Общие впечатления о Справочном центре Google
- Справочный центр
- Сообщество
Search Console
Слишком мелкий шрифт и Интерактивные элементы расположены слишком близко
Две наиболее часто встречающиеся ошибки в Google Search Console. Вот как они выглядят:
Зачастую ничего страшного в них нет, иногда Google ошибочно выдает ошибку и после проверки она пропадает. Вот что нужно сделать:
Кликаем по ошибке и переходим на страницу с адресами, на которых обнаружена эта ошибка. Дальше наводим на первый адрес и жмем иконку Проверить URL.
Нам открывается проверка по URL. Здесь мы нажимаем на кнопку Проверить страницу на сайте.
Начинается проверка страницы, обычно занимает меньше минуты.
Если проблемы на страницы нет, мы получим в результате следующее сообщение:
В таком случае вам не нужно ничего делать, страница оптимизирована и проблем нет. Google через время снимет эту ошибку, нужно дать 1-2 недели на обновление кеша Google. Сразу ошибка в консоли не пропадает, только через время.
В случае, если после проверки ошибки остались, нужно открывать страницу на мобильном и смотреть, где слишком маленькой шрифт, либо элементы расположены близко к друг другу.
Дополнительно вы можете проверить вашу страницу в этом сервисе Google для проверки оптимизации на мобильном.
Вам помог ответ?
Похожие вопросы
Открепить
Слишком мелкий шрифт и Интерактивные элементы расположены слишком близко
Две наиболее часто встречающиеся ошибки в Google Search Console. Вот как они выглядят:
Зачастую ничего страшного в них нет, иногда Google ошибочно выдает ошибку и после проверки она пропадает. Вот что нужно сделать:
Кликаем по ошибке и переходим на страницу с адресами, на которых обнаружена эта ошибка. Дальше наводим на первый адрес и жмем иконку Проверить URL.
Нам открывается проверка по URL. Здесь мы нажимаем на кнопку Проверить страницу на сайте.
Начинается проверка страницы, обычно занимает меньше минуты.
Если проблемы на страницы нет, мы получим в результате следующее сообщение:
В таком случае вам не нужно ничего делать, страница оптимизирована и проблем нет. Google через время снимет эту ошибку, нужно дать 1-2 недели на обновление кеша Google. Сразу ошибка в консоли не пропадает, только через время.
В случае, если после проверки ошибки остались, нужно открывать страницу на мобильном и смотреть, где слишком маленькой шрифт, либо элементы расположены близко к друг другу.
Дополнительно вы можете проверить вашу страницу в этом сервисе Google для проверки оптимизации на мобильном.
Вам помог ответ?
Похожие вопросы
Статус текущего тикета при откреплении
Открепить
В «Google Search Console» есть штука называемая «Mobile-Friendly Test tool«, на результаты которой опирается гугл решая индексировать ли страницу или нет.
Относительно с недавних (с конца 2016-го года) пор гугл ударился в «Mobile-first Indexing», а потому теперь рейтинг страницы и позиция в поисковой выдаче напрямую зависит от степени её оптимизированости под мобильные устройства:
Подготовка к индексированию с приоритетом мобильного контента
При индексировании, ориентированном на мобильные устройства, рейтинг страниц зависит главным образом от их мобильной версии. Раньше релевантность контента оценивалась в первую очередь на основе версии для компьютеров. Поскольку большинство пользователей сейчас открывают Google Поиск на мобильных устройствах, сканирование и индексирование страниц теперь выполняет в первую очередь робот Googlebot для смартфонов.
Проблемы Mobile-Friendly Test tool
Главная проблема с «Mobile-Friendly Test tool» в том, что работает оно криво и косо, что проявляется в ничем не обоснованных ошибках типа:
Исправьте 2 указанные ниже проблемы
- Слишком мелкий шрифт
- Интерактивные элементы расположены слишком близко
При этом, а ни изменение размера шрифта, ни расстояние между элементами не решают проблему.
В правой части окна результатов проверки «Mobile-Friendly Test tool» можно видеть «Проблемы при загрузке страницы. Подробнее», кликнув на «Подробнее» нашему взору откроются «Данные о ходе загрузки страницы»:
Страница частично загружена
Не удалось загрузить все элементы страницы. Это может повлиять на то, как Google видит и обрабатывает вашу страницу. Устраните проблемы.
Далее по тексту там будем видеть «Не удалось загрузить 30 ресурсов страницы», среди которых в основном будут изображения с типом «Изображение» и статусом «Другая ошибка».
Изображение — Другая ошибка
Данный глюк, а это именно глюк, в «Mobile-Friendly Test tool» существует довольно давно, выполоскал мозги многим СЕО-пропихаторам и вызвал множественные холивары на просторах Интернетов:
Гугл не видит большинство картинок на сайте — Cправка — Search Console
…
Это проблема инструмента проверки мобильности, он просто ограничен в ресурсах и на ошибке сбивается, что приводит к вываливанию в «другую ошибку». Причин может быть море, начиная от размера картинок и заканчивая размером js-скриптов и css.
Уже более года обещают пофиксить данный инструмент.
Аналогичные глюки имеют место быть и при проверке нашего сайта, который на данный момент расположен на VPS, а значит мы имеем полный доступ к лог-файлам сервера в режиме реального времени. Для чистоты эксперимента был полностью отключен брандмауэр, также логи были изучены на предмет наличия записей о превышении лимита подключений.
Так вот, проверка страницы в «Mobile-Friendly Test tool» и одновременный анализ лог-файлов сервера показал, что выдавая «Другая ошибка» по изображениям, — в отрезок времени с начала проверки и до момента завершения эти самые изображения никем, включая робота гугла, не запрашивались, записей о превышении лимитов на подключения не наблюдалось.
По неизвестным причинам аналогичные глюки могут быть с другими типами, например «Скрипт Другая ошибка».
Сообщения из консоли JavaScript
Ещё один глюкодром «Mobile-Friendly Test tool«.
Uncaught TypeError: $(...).tooltip is not a function at HTMLDocument.<anonymous> ...
Примечательно, что в консоли браузера никаких подобных ошибок не наблюдается, и при проверке другой страницы с теми же скриптами и порядком их загрузки «Mobile-Friendly Test tool» подобными ошибками не глюкает.
Другие глюки
«Mobile-Friendly Test tool» может засыпать также и другим бредом в стиле «preloaded using link preload but not used«:
The resource /…/*.min.js was preloaded using link preload but not used within a few seconds from the window’s load event. Please make sure it has an appropriate `as` value and it is preloaded intentionally.
Глюкам «Mobile-Friendly Test tool» нет счёта, потому перечислить их все не представляется возможным.
Выводы
Выводы думаю здесь очевидны:
- «Mobile-Friendly Test tool» — совсем не «Friendly» и как «Test tool» рассматриваться не может;
- От этой байды у многих не по праву страдает посещаемость;
- Гуглу очевидно многие лета плевать на «кривожопость» ихней системы оценки сайтов на оптимизированость под мобильные устройства.
Кроме всего прочего у многих переходы с гугла упали в результате вынимания мозгов «рэкаптчей» при каждом поисковом запросе в поиск даже не смотря на то, что ты «залогинен» в гугляцком аккаунте.
Сам давно почти не пользуюсь гугл поиском из-за его постоянных подозрений что я робот даже при всём том, что ты «залогинен» в гугляцком аккаунте и несколько секунд назад уже пробивал ту конченную «рэкаптчу» отмечая там пачками мосты/холмы/машины/пешеходные переходы.
Особую ненависть испытываю ко всем сайтам, а вернее их разработчикам/админам, которые используют «рэкаптчу» и обхожу такие сайты стороной. ИМХО иногда нет иной возможности выйти в сеть кроме как через ТОР, а пришибленная «рэкаптча» кроме своей жуткой «кумарности» ещё довольно часто тупо и наглухо блокирует ТОР сети.
В последние 2-3 года поиск от гугла превратился в глюкодромное, рэкаптчей мозгвыносящее … лала-ла-лала-ла. А теперь все вместе: Гугло х.йло! Лала-ла-лала-ла.
Недавно, сидя дома на самоизоляции, я решил помочь своим хорошим знакомым в том чтобы подлатать и немного приподнять их сайт в поисковиках. О всех деталях я рассказывать не буду, ибо во-первых, это затянется на несколько страниц текста мелким шрифтом, а во-вторых – каждый сайт индивидуален, и работающие в одном случае методики не дают абсолютно никакого результата в другом. Но об одном интересном обстоятельстве, найденном мною, я все-таки хотел бы рассказать.
Сталкивались ли Вы когда-нибудь, когда Ваш сайт, имеющий мобильную версию, или даже просто страница, даже имеющая адаптивный дизайн – в поисковой выдаче Гугла помечается, как не оптимизированная для мобильных устройств? Более того – при проверке специальным инструментом Google-a, так называемым “Инструмент Проверки в Search Console” выдается весьма негативный результат вот такого плана:
Т.е. Гугл уверен, что ваш сайт не оптимизирован для мобильных устройств из-за того, что там “слишком мелкий шрифт”, “Контент шире экрана” и “Интерактивные элементы расположены слишком близко” даже при том, что остальные сайты проверки (такие как Responsinator, позволяющие увидеть, как Ваш сайт выглядит на различных мобильных девайсах – от богомерзких iPhone с iPad до дьявольских Android) – показывают отличный результат и mobile-friendly страницы. Кстати, очень полезный сайт, если у вас нет набора различных девайсов для тестирования, как же ваш сайт выглядит на всем, чем ни попадя, и адаптации его под них.
Ну и что же за этим следует? К сожалению – то, что вслед за этим Google начинает пессимизировать сайт, опуская его в своей поисковой выдаче где-то на четвертую-пятую страницу. И если, например, мне – на мнение Google плевать вообще с высокой колокольни (поскольку мой сайт – это не коммерческий проект, посещаемость – это то, что заботит меня меньше всего, и то, как он выглядит у меня на мобильнике – меня вполне устраивает), то сайтам, которым важна посещаемость и трафик – это важно.
Вот и в данном случае мои друзья столкнулись с такой проблемой, им это было важно, ну а поскольку их сайт был на WordPress, то полез я смотреть, что это такое, и из-за чего Search Console выдает ошибку оптимизации для мобильных устройств. И первое, что привлекло мое внимание, когда я воспользовался их этим инструментом – было то, что сайт действительно довольно криво отображался, как будто мобильной/адаптивной версии у него не было вовсе. Хотя необходимый тег, который говорит отображать контент адаптивно, т.е.
<meta name=«viewport» content=«width=device-width, initial-scale=1»> |
конечно же был задан в файле header.php
Стало ясно, что Гугл просто тупо не видит установленых стилей, ака css. Ну глупенький, чего с него возьмешь. Но надо разбираться, почему. В этих ваших интернетах нашел, что проверка оптимизации для мобильных устройств работает через Google Bot. Ага, подумал я. Если используется Гугл Бот, то единственное, что ему может помочь увидеть необходимые стили, это запрет в robots.txt лезть туда, где они лежат. Выгружаю из корня сайта этот файл, открываю в notepad++, и начинаю пристально изучать. Выглядит он примерно так (сайт в хостах я указал свой, поскольку не хочу светить тот, над которым я работал на самом деле):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
User—agent: * Disallow: */feed Disallow: /feed Disallow: */*/feed/*/ Disallow: */*/feed Disallow: /?feed= Disallow: /wp—trackback Disallow: /wp—feed Disallow: /wp—comments Disallow: /wp—admin/ Disallow: /wp—content/plugins Disallow: /wp—content/cache Disallow: /wp—content/themes Disallow: /wp—login.php Disallow: /wp—register. Disallow: /cgi—bin Disallow: /wp—includes/ Disallow: /*?* Disallow: /*? Disallow: /2011 Disallow: /2012 Disallow: /2013 Disallow: /2014 Disallow: /author Disallow: /tag Disallow: /archive Disallow: /category Disallow: /page Disallow: *?replytocom= Disallow: /comments Host: chewriter.ru Sitemap: http://chewriter.ru/sitemap.xml |
Понятно, что инструкция Disallow как раз запрещает ему (гуглоботу) заходить в определенные каталоги, и считывать из них то, что там лежит, в нашем случае – CSS стили (масло масленое, но да бог с ним). Также понятно, что все, начиная с Disallow: /2011 к делу отношения иметь не может – это просто дубли страниц, выводимые движком Вордпресс при поиске через архив/календарь/теги и т.п. А вот со всем, что выше – предстоит серьезно разобраться. Ну что-ж, оставляю в файле robots.txt только первую строку User-agent: *, и нижнюю часть, которая начинается с /2011, заливаю его обратно на сервер, натравливаю на сайт проверку Гугла, и – Вуаля! Страница оптимизирована для мобильных устройств:
Значит, наше предположение, что причина в файле robots.txt, было верно. Осталось понять, какие же именно строки мешают ему увидеть ее всегда таковой. Первой, конечно под подозрение попала
Disallow: /wp-content/themes
И действительно – при ее добавлении сайт перестает быть мобайл-френдли. Но как оказалась, мешает не только она. Поэтому, исключив её, начинаем добавлять по одной-двум сначала те, что без подозрений, такие как:
Disallow: /wp-trackback
Disallow: /wp-feed
Disallow: /wp-comments.
И т.д. И вот когда дошли до примерно пяти-шести особо подозрительных, первой вывалилась
Disallow: /*?
При включении которой в файл роботс все опять становилось плохо. Ну и после этого стало все очевидно: проверили еще и
Disallow: /*?*
И увидели, что она тоже мешает. Что ж, все понятно, берем исходный robots.txt, удаляем из него три эти строчки:
Disallow: /wp—content/themes Disallow: /*? Disallow: /*?* |
А все остальные – оставляем, и видим, что Google теперь видит наш сайт на WordPress и страницы оптимизированными для мобильных устройств.
Время открывать шампанское и ждать переползания на 1-2 страницу поисковой выдачи в Гугли 🙂
1
Как победить ошибку при проверке mobile-friendly сайта в Google?
11.01.2019
Не адаптировать сайт под мобильные устройства уже стало моветоном — это как позвать домой кучу гостей и при этом не убраться и ничего не приготовить. Навряд ли к вам зайдут еще раз. Чтобы похожего не происходило и вы не теряли клиентов, важно сделать так, чтобы Ваш сайт везде был красив, свеж и обаятелен как Фредди Меркьюри в свои лучшие годы.
Одной из самых популярных CMS является «1С-Битрикс: Управление сайтом». Именно этот продукт сегодня будет в центре внимания.
В продукт «1С-Битрикс: Управление сайтом» встроен комплекс решений для выполнения требований Google к сайтам — используется современная технология адаптивной верстки с использованием Bootstrap 3, объединение и сжатие javascript и CSS-файлов, ускорение сайта 2.0, оптимизация изображений и перенос javascript вниз страницы. Это все, конечно, прекрасно, но не помешает сделать проверку, все ли работает правильно.
Для начала давайте посмотрим насколько Ваш сайт дружелюбен для мобильных устройств с помощью следующих инструментов:
Mobile-Friendly Test
Тест поможет выявить следующие ошибки:
Google Page Speed Insights —
Этот инструмент показывает отчет по одной странице, где анализируется скорость загрузки, выдается балл оптимизации (отличный результат больше 85 баллов) и предлагаются решения по обнаруженным ошибкам.
После того как Вы убедились, что сайту есть куда стремится в адаптации под мобильные устройства, переходим к конкретным шагам.
- Проверьте ваш файл robots.txt, часто в нем закрывают от индексации папку /bitrix/, вместе с ней файлы стилей, изображений и скриптов. При анализе бот Google видит страницы без дизайна и это не дает пройти тест вашему сайту. Откройте необходимые папки для индексации для прохождения проверки.
- Обязательно подключите технологию композитного сайта на любой проект 1С-Битрикс. Также можете использовать инструмент “Скорость сайта” для постоянного мониторинга.
- Оптимизируйте CSS и JS. Включите объединение и сжатие CSS и JS. Это уменьшает число файлов с 44 до 16 (на 160%) и размер js и css почти в 2 раза.
- Перенесите JS вниз страницы. Как правило, после переноса JS вниз страницы скрипты продолжают работать правильно, но если Ваша ситуация требует запрета на перенос вниз, задайте его атрибутом data-skip-moving=»true».
При работе с инструментом учтите несколько моментов:
— перенос JavaScript происходит по тегам <script></script>
— не учитываются сложные конструкции, например, HTML-комментарии
— document.write() будет работать неправильно
— инструмент может настраиваться отдельно для страниц и шаблонов
- Оптимизация изображений. Вы потеряете доверие Google Page Speed, если Ваши картинки будут тяжелы как утро после Нового года, и при этом отображены в небольшом размере.
- Кроме сторонних ресурсов, вы можете обратится к встроенному инструменту 1С-Битрикс. При включении CDN для вашего сайта и отмеченной строке “Оптимизировать ресурсы”, изображения будут отдаваться CDN в оптимизированном виде, не требуя предварительной обработки. Кроме того CDN оптимизирует файлы JS и CSS.
- И конечно же, воспользуйтесь советами самого Google Page Speed Insight
Итого: проверьте все из ниже перечисленного и будет вам счастье!
Mobile-Friendly Test
Google PageSpeed Insights
Инструменты 1С-Битрикс
Задавайте вопросы!
Возврат к списку
What is the meaning of Text too small to read in the mobile usability section of Google search console?
asked Feb 20, 2020 at 11:29
Google’s official description is:
«The font size for the page is too small to be legible and would
require mobile visitors to “pinch to zoom” in order to read.»
This means you should use legible font sizes in order to optimize your text for reading and provide a better user experience when browsing your website on mobile devices.
answered Feb 20, 2020 at 12:03
1
Have you tried increasing the font size? It may sound daft but normally the obvious is the simple answer.
Most CMS have an easy option to change the font size across the whole website and you can test it to make sure it does not have an adverse effect on larger screens.
The other point that springs to mind is to make sure you don’t have any really small text on the page, check your footer for one, but also if the domain has spammy text hidden with really small text size that won’t help.
It might help if you could share the text size you are using if none o the above help.
answered Feb 21, 2020 at 6:53
I had the same «text too small to read». My footnote font setting was:
.base {
font-family: Arial, Helvetica, sans-serif;
text-align: center;
font-size: calc(0.6em + 0.4vw);
text-shadow: 0 0 8px #FFF;
}
I am now trying
.base {
font-family: Arial, Helvetica, sans-serif;
text-align: center;
font-size: calc(0.8em + 0.4vw);
text-shadow: 0 0 8px #FFF;
}
It will be interesting to see if the increase from calc(0.6em + 0.4vw)
to calc(0.8em + 0.4vw)
is sufficient to make it acceptable.
John Conde♦
85.9k26 gold badges142 silver badges239 bronze badges
answered Sep 12, 2020 at 15:49
1
I resolved this by making sure Google had spidered my CSS file. Once it did that, the page registered correctly and the error went away.
answered Jun 30, 2021 at 17:05
SteveSteve
1115 bronze badges
1
What is the meaning of Text too small to read in the mobile usability section of Google search console?
asked Feb 20, 2020 at 11:29
Google’s official description is:
«The font size for the page is too small to be legible and would
require mobile visitors to “pinch to zoom” in order to read.»
This means you should use legible font sizes in order to optimize your text for reading and provide a better user experience when browsing your website on mobile devices.
answered Feb 20, 2020 at 12:03
1
Have you tried increasing the font size? It may sound daft but normally the obvious is the simple answer.
Most CMS have an easy option to change the font size across the whole website and you can test it to make sure it does not have an adverse effect on larger screens.
The other point that springs to mind is to make sure you don’t have any really small text on the page, check your footer for one, but also if the domain has spammy text hidden with really small text size that won’t help.
It might help if you could share the text size you are using if none o the above help.
answered Feb 21, 2020 at 6:53
I had the same «text too small to read». My footnote font setting was:
.base {
font-family: Arial, Helvetica, sans-serif;
text-align: center;
font-size: calc(0.6em + 0.4vw);
text-shadow: 0 0 8px #FFF;
}
I am now trying
.base {
font-family: Arial, Helvetica, sans-serif;
text-align: center;
font-size: calc(0.8em + 0.4vw);
text-shadow: 0 0 8px #FFF;
}
It will be interesting to see if the increase from calc(0.6em + 0.4vw)
to calc(0.8em + 0.4vw)
is sufficient to make it acceptable.
John Conde♦
85.9k26 gold badges142 silver badges239 bronze badges
answered Sep 12, 2020 at 15:49
1
I resolved this by making sure Google had spidered my CSS file. Once it did that, the page registered correctly and the error went away.
answered Jun 30, 2021 at 17:05
SteveSteve
1115 bronze badges
1
“Страница не оптимизирована для мобильных устройств” — такое сообщение выдает Mobile friendly test. Да и в Search Console ошибки по 7 страницам в блоке “Удобство для мобильных”.
Что странно, есть страницы, которые проходят по требованиям оптимизации.
В качестве причин Mobile friendly test выдает:
- Слишком мелкий шрифт;
- Интерактивные элементы расположены слишком близко.
Детализации нет. Какой шрифт для Google Mobile friendly test слишком мелкий? 12px — это мелкий или уже нормально? В каких блоках его хотя бы искать?
Смотрю вкладку “Подробнее”. Очередные жалобы Google на скрипты Метрики. Да, когда же ты уже перестанешь ругаться на нее? Жалобы на то, что он не может прочитать запрещенные в robots.txt файлы. Ну да, понятно, но какое отношение это имеет к мелким шрифтам?
Странно, что страница на скриншоте загружается совсем без стилей, хотя на в телефоне открывается как положено.
Пробуем исправить весь шрифт на минимум 14px, но это не помогает. Даже предупреждение никуда не исчезло.
На форуме searchengines.guru нахожу, что Google может не проиндексировать какой-либо css и из-за этого выдавать случайные ошибки в типа “слишком мелкий шрифт” и далее по списку.
Снова смотрю вкладку “Подробнее”. Вижу, что Google не может проиндексировать вкладку /wp-content/. Я ее сама запретила в robots.txt, уже не помню точно почему, но видимо кто-то индексировал что-то не нужное.
Убираю строку в robots.txt: вуаля! Страница оптимизирована для мобильных устройств и на скриншоте все отображается нормально. И шрифты все в порядке и интерактивные элементы уже не близко.
Косяк мой, не спорю. Я заблокировала всю тему для индексации Google. Но почему же нельзя выводить адекватные ошибки? Написать что-то вроде: “Мы не можем получить доступ к … обратите внимание”.
На минуточку, Яндекс при этом совсем не был против запрета индексации. Их сервис проверки выдавал полное соответствие требованиям.
Вывод: если Google пишет о проблемах, проверяйте все.
С 2013 года работаю с поисковой оптимизацией (SEO).
C 2014 года работаю с поисковой рекламой (Яндекс.Директ/Google Ads).
С 2020 года работаю с рекламой в соц. сетях (Facebook, Instagram, VK).
Работала с управлением репутацией и SMM.
Мой опыт — это ваши сэкономленные деньги.
Я консультирую всех, кто обращается ко мне. Это бесплатно. Задавайте вопросы. Буду рада помочь.
В «Google Search Console» есть штука называемая «Mobile-Friendly Test tool«, на результаты которой опирается гугл решая индексировать ли страницу или нет.
Относительно с недавних (с конца 2016-го года) пор гугл ударился в «Mobile-first Indexing», а потому теперь рейтинг страницы и позиция в поисковой выдаче напрямую зависит от степени её оптимизированости под мобильные устройства:
Подготовка к индексированию с приоритетом мобильного контента
При индексировании, ориентированном на мобильные устройства, рейтинг страниц зависит главным образом от их мобильной версии. Раньше релевантность контента оценивалась в первую очередь на основе версии для компьютеров. Поскольку большинство пользователей сейчас открывают Google Поиск на мобильных устройствах, сканирование и индексирование страниц теперь выполняет в первую очередь робот Googlebot для смартфонов.
Проблемы Mobile-Friendly Test tool
Главная проблема с «Mobile-Friendly Test tool» в том, что работает оно криво и косо, что проявляется в ничем не обоснованных ошибках типа:
Исправьте 2 указанные ниже проблемы
- Слишком мелкий шрифт
- Интерактивные элементы расположены слишком близко
При этом, а ни изменение размера шрифта, ни расстояние между элементами не решают проблему.
В правой части окна результатов проверки «Mobile-Friendly Test tool» можно видеть «Проблемы при загрузке страницы. Подробнее», кликнув на «Подробнее» нашему взору откроются «Данные о ходе загрузки страницы»:
Страница частично загружена
Не удалось загрузить все элементы страницы. Это может повлиять на то, как Google видит и обрабатывает вашу страницу. Устраните проблемы.
Далее по тексту там будем видеть «Не удалось загрузить 30 ресурсов страницы», среди которых в основном будут изображения с типом «Изображение» и статусом «Другая ошибка».
Изображение — Другая ошибка
Данный глюк, а это именно глюк, в «Mobile-Friendly Test tool» существует довольно давно, выполоскал мозги многим СЕО-пропихаторам и вызвал множественные холивары на просторах Интернетов:
Гугл не видит большинство картинок на сайте — Cправка — Search Console
…
Это проблема инструмента проверки мобильности, он просто ограничен в ресурсах и на ошибке сбивается, что приводит к вываливанию в «другую ошибку». Причин может быть море, начиная от размера картинок и заканчивая размером js-скриптов и css.
Уже более года обещают пофиксить данный инструмент.
Аналогичные глюки имеют место быть и при проверке нашего сайта, который на данный момент расположен на VPS, а значит мы имеем полный доступ к лог-файлам сервера в режиме реального времени. Для чистоты эксперимента был полностью отключен брандмауэр, также логи были изучены на предмет наличия записей о превышении лимита подключений.
Так вот, проверка страницы в «Mobile-Friendly Test tool» и одновременный анализ лог-файлов сервера показал, что выдавая «Другая ошибка» по изображениям, — в отрезок времени с начала проверки и до момента завершения эти самые изображения никем, включая робота гугла, не запрашивались, записей о превышении лимитов на подключения не наблюдалось.
По неизвестным причинам аналогичные глюки могут быть с другими типами, например «Скрипт Другая ошибка».
Сообщения из консоли JavaScript
Ещё один глюкодром «Mobile-Friendly Test tool«.
Uncaught TypeError: $(...).tooltip is not a function at HTMLDocument.<anonymous> ...
Примечательно, что в консоли браузера никаких подобных ошибок не наблюдается, и при проверке другой страницы с теми же скриптами и порядком их загрузки «Mobile-Friendly Test tool» подобными ошибками не глюкает.
Другие глюки
«Mobile-Friendly Test tool» может засыпать также и другим бредом в стиле «preloaded using link preload but not used«:
The resource /…/*.min.js was preloaded using link preload but not used within a few seconds from the window’s load event. Please make sure it has an appropriate `as` value and it is preloaded intentionally.
Глюкам «Mobile-Friendly Test tool» нет счёта, потому перечислить их все не представляется возможным.
Выводы
Выводы думаю здесь очевидны:
- «Mobile-Friendly Test tool» — совсем не «Friendly» и как «Test tool» рассматриваться не может;
- От этой байды у многих не по праву страдает посещаемость;
- Гуглу очевидно многие лета плевать на «кривожопость» ихней системы оценки сайтов на оптимизированость под мобильные устройства.
Кроме всего прочего у многих переходы с гугла упали в результате вынимания мозгов «рэкаптчей» при каждом поисковом запросе в поиск даже не смотря на то, что ты «залогинен» в гугляцком аккаунте.
Сам давно почти не пользуюсь гугл поиском из-за его постоянных подозрений что я робот даже при всём том, что ты «залогинен» в гугляцком аккаунте и несколько секунд назад уже пробивал ту конченную «рэкаптчу» отмечая там пачками мосты/холмы/машины/пешеходные переходы.
Особую ненависть испытываю ко всем сайтам, а вернее их разработчикам/админам, которые используют «рэкаптчу» и обхожу такие сайты стороной. ИМХО иногда нет иной возможности выйти в сеть кроме как через ТОР, а пришибленная «рэкаптча» кроме своей жуткой «кумарности» ещё довольно часто тупо и наглухо блокирует ТОР сети.
В последние 2-3 года поиск от гугла превратился в глюкодромное, рэкаптчей мозгвыносящее … лала-ла-лала-ла. А теперь все вместе: Гугло х.йло! Лала-ла-лала-ла.