Как проверить, есть ли у сайта мобильная версия

Как проверить, есть ли у сайта мобильная версия
У сайта может быть «мобильная версия» тремя разными способами. Это может быть адаптивный сайт, который перестраивается сам, отдельная мобильная версия со своим URL или десктопная страница, которая просто сжимается и надеется на лучшее. Если вам нужно понять, как проверить есть ли у сайта мобильная версия, начните именно с этого различия. Последний вариант встречается часто.
Прежде чем что-то оценивать, определите цель. Если вы хотите понять как проверить, есть ли у сайта страница контактов, вы ищете один тип сигнала; здесь же вы проверяете поведение на экране, навигацию и работу на разных устройствах. Вопрос другой — и доказательства нужны другие. Всё просто, но люди часто это путают.
Мобильная версия должна не просто «открываться» на телефоне. Она должна помещаться на маленьких экранах, сохранять читаемость текста и оставлять доступ к основной задаче без постоянного увеличения и прокрутки. Иными словами, важно как узнать адаптивный сайт или нет, а не ограничиться проверкой того, что страница вообще загрузилась. Одного «гамбургер-меню» ещё недостаточно. Как и крошечной версии десктопного макета.
1. Определите, что именно вы считаете «мобильной версией»
Начните с одного решения: вы ищете отдельный мобильный сайт, адаптивную верстку или мобильный сценарий вроде предложения установить приложение или упрощённого меню? Этот выбор меняет то, что вы проверяете в первую очередь.
Отдельный мобильный сайт часто использует другой поддомен, например m.example.com, или отдельный путь. Адаптивная верстка обычно сохраняет тот же URL и меняет страницу с помощью CSS. Мобильный сценарий может оставаться на той же странице, но показывать другую навигацию, меньше колонок или предложение установить приложение. Это не одно и то же.
Если сайт старый, мобильная версия может быть очевидной. Если сайт более новый, мобильная версия может быть встроена в дизайн, а не вынесена на отдельный адрес. Обращайте на это внимание.
Практичная подсказка: сайт, который меняет только размер шрифта, едва ли можно назвать полноценной мобильной версией. А вот если меняются меню, интервалы, медиа-блоки и форма — это уже настоящая работа.
2. Проверьте сайт в обычном десктопном браузере, не меняя устройство
Сначала откройте страницу в обычном десктопном браузере. Затем постепенно сужайте окно, а не делайте это одним резким шагом. Смотрите, что меняется на 1200 пикселях, затем на 1024 и на 768. Эти значения важны, потому что многие макеты ломаются именно в этих точках.
Смотрите на поведение, а не только на внешний вид. Схлопывается ли верхняя навигация в одно меню? Уходят ли боковые панели под основной контент? Становится ли большое изображение меньше, не выталкивая текст за пределы экрана? Это признаки того, что сайт был рассчитан на адаптацию.
Сайт может притворяться удобным для мобильных устройств, просто уменьшая всё подряд. Этого недостаточно. Пользователю всё равно нужны читаемые абзацы, кнопки, по которым можно нажимать, и формы, которые не требуют горизонтальной прокрутки.
Откройте страницу с длинной формой. Если при меньшей ширине подписи накладываются друг на друга, мобильная версия слабая. Если поля аккуратно выстраиваются друг под другом, а кнопка отправки остаётся видимой, мобильная версия, вероятно, продумана хорошо.
Для быстрой перепроверки можно сравнить структуру с другой страницей на том же домене, например как проверить, есть ли у сайта раздел с условиями доставки. На сайтах страницы с правилами часто менее гибкие, чем товарные страницы, и эта разница может показать, применялись ли адаптивные правила ко всему сайту или только к главной странице.
3. Проверьте исходный код и CSS на наличие мобильной настройки
Посмотрите исходный код или откройте инструменты разработчика. Найдите meta-тег viewport. Если там есть width=device-width и разумное начальное масштабирование, это сильный признак того, что сайт создавался с учётом мобильных экранов.
Затем проверьте CSS-файлы. Адаптивный код обычно содержит media queries с точками перелома вроде 768px, 1024px или 480px. Не нужно читать всё подряд. Одной-двух удачно расположенных точек перелома уже достаточно, чтобы понять многое.
Ищите и мобильные ассеты. У изображения могут быть версии меньшего размера для экранов с низкой скоростью соединения. Навигационный скрипт может загружаться только при узком экране. Начертание шрифта может меняться ради лучшей читаемости. Такие детали важны, потому что они показывают намерение, а не случайность.
Если в исходнике везде фиксированная ширина, стоит насторожиться. Фиксированные макеты могут открываться на телефоне, но это ещё не значит, что у сайта есть мобильная версия. Возможно, это просто десктопная страница, сжатая до меньшего окна.
Вот что многие упускают: исходный код может показывать поддержку мобильных устройств даже тогда, когда визуально страница выглядит очень просто. Чистая страница не всегда проста внутри. А перегруженная страница не всегда сломана.
4. Сравните поведение на типичных мобильных ширинах
Проверьте несколько стандартных ширин в браузере. Попробуйте 375 пикселей, 390 пикселей и 414 пикселей для современных телефонов, а затем 768 пикселей для просмотра в формате планшета. Этот диапазон быстро выявляет большинство проблем с версткой.
На 375 пикселях проверьте, остаётся ли контент в пределах экрана. На 390 пикселях — достаточно ли крупные кнопки для пальца. На 414 пикселях — нет ли пустого пространства по бокам или обрезанных баннеров. Это мелкие признаки, но они складываются в общую картину. Именно так проще всего проверить мобильную версию сайта онлайн, если под рукой есть браузерные инструменты и эмуляция экрана.
Хорошая мобильная версия аккуратно перестраивается. Слабая просто уменьшается. Между «помещается» и «работает» — большая разница.
Проверьте ту же страницу в портретной и альбомной ориентации. Иногда страница хорошо ведёт себя в одном положении и становится неудобной в другом. Галерея может слишком жёстко фиксировать изображения, а таблица — стать нечитаемой. Таблицы особенно показательны.
Если на странице есть сравнительная таблица, уменьшите ширину и посмотрите, что произойдёт. Правильная мобильная версия может складывать строки друг под другом или давать контролируемую горизонтальную прокрутку. Плохая — обрезает последний столбец. Именно такое пользователи замечают очень быстро.
5. Ищите отдельные мобильные URL или перенаправления по устройству
Старые сайты иногда отправляют телефоны на другой адрес. Вы можете увидеть m.example.com, mobile.example.com или URL, содержащий /mobile/ или /amp/. После загрузки страницы на телефоне или в узком окне эмуляции внимательно посмотрите на адресную строку.
Перенаправления по устройству могут происходить незаметно. Десктопный пользователь видит одну страницу, а пользователь телефона попадает в другое место. Это может указывать на отдельную мобильную версию, но может означать и устаревшую схему, которую так и не обновили.
Обращайте внимание на перенаправления, которые происходят до полной загрузки страницы. Быстрый переход с одного домена на другой часто означает, что сервер определяет тип устройства. Если редирект ведёт на упрощённую страницу, сайт, возможно, делали для старых телефонов, а не для современных адаптивных экранов.
Не делайте поспешных выводов. Мобильный URL не всегда означает, что на телефоне сайт работает лучше. Иногда это значит лишь то, что сайт старый, медленный и его сложнее поддерживать.
Один простой признак — последовательность. Если редирект есть только у главной страницы, а внутренние страницы его не имеют, мобильная версия, скорее всего, неполная.
6. Проверьте, меняется ли сайт в зависимости от user agent
Откройте инструменты разработчика и переключите user agent на профиль телефона. Затем обновите страницу. Если содержимое меняется, сайт отдаёт другой HTML или CSS для мобильных устройств.
Это важно, потому что некоторые сайты скрывают мобильную версию за определением устройства. В десктопном браузере они могут показывать полный макет, а при мобильном user agent — более узкое меню, другие изображения или даже иные текстовые блоки. Одним лишь изменением размера окна этого не увидеть.
Попробуйте хотя бы два user agent: один современный профиль iPhone и один Android. Если сайт ведёт себя по-разному, зафиксируйте точное отличие. Изменение навигации — это значимо. Изменение аналитических скриптов — недостаточно.
Если страница ломается только под одним user agent, возможно, мобильная версия была неудачно «подлатана» под конкретные устройства вместо того, чтобы быть нормально построенной. Это признак плохой поддержки. А ещё это может приводить к странным багам, которые проявляются только на отдельных телефонах.
Для отдельной проверки структуры сайта можно сравнить его с как проверить, есть ли у сайта страницы условий использования. Юридические страницы часто хуже адаптированы, чем товарные, поэтому на них удобно выявлять частичную поддержку мобильных устройств.
7. Проверьте публичные веб-архивы и поисковые сниппеты на наличие прошлых мобильных вариантов
Публичные архивы могут показать, существовала ли мобильная версия раньше. Найдите сайт в Wayback Machine или другом архиве и изучите несколько снимков за разные годы, а не один. Мобильная страница 2018 года может рассказать историю, которую главная страница 2026 года уже скрывает.
Архивные URL могут показать старые мобильные поддомены, перенаправления под конкретные устройства или отдельные шаблоны. Полезны и поисковые сниппеты. Если в проиндексированных результатах виден мобильный путь или AMP-страница, это говорит о том, что сайт когда-то публично показывал мобильную версию.
Не переоценивайте один снимок. Архивы могут не сохранять стили, скрипты или изображения. Но если три разных снимка показывают URL-структуру под телефон, это уже сильное доказательство.
Можно также сравнить кэшированный текст рядом с заголовком страницы. Если раньше поисковая выдача показывала короткий мобильный заголовок, а теперь — длинный десктопный, значит, за это время сайт, вероятно, изменил подачу.
Проверка архивов полезна ещё и по практической причине: некоторые сайты убирают мобильную версию, но старые ссылки не очищают. Пользователи приходят из поиска или закладок и попадают на нерабочие мобильные пути. Такие проблемы обычно остаются незамеченными, пока кто-то не проверит их вручную.
8. Определите, какая именно мобильная поддержка у сайта есть на самом деле
К этому моменту вы уже должны уметь сформулировать результат одним предложением. Скажите, сайт адаптивный, использует отдельную мобильную версию или почти не оптимизирован для мобильных устройств. Это утверждение должно опираться на 3 конкретных наблюдения, а не на догадку.
Адаптивный сайт обычно сохраняет один URL, показывает понятные точки перелома и перестраивает навигацию на меньших ширинах. Отдельная мобильная версия обычно использует другой URL или перенаправление по user agent. Слабая мобильная настройка обычно просто уменьшает десктопный дизайн, обрезает содержимое или делает формы неудобными.
Если вам нужен быстрый шаблон отчёта, используйте такой порядок: структура URL, поведение макета и доказательства из исходного кода. Три пункта. Для базового отчёта этого достаточно.
Например: «Сайт адаптивный. Он сохраняет тот же URL, использует viewport-тег и на 390 пикселях переносит боковую панель под основной контент». Это понятно, коротко и проверяемо.
Если вы документируете старый сайт для справки, пишите точно. Укажите конкретный мобильный путь, поведение на устройстве и ширину, при которой меняется макет. Размытая фраза вроде «работает на телефоне» никому не помогает.
И последний тест: если сайт предлагает только мобильное меню, но при этом прячет важный контент за крошечными ссылками, это ещё не сильная мобильная версия. Это всего лишь мобильное меню. А это разные вещи.



