Способы реализации мобильной версии сайта через призму SEO
6 способов реализации мобильной версии сайта и их разбор с точки зрения SEO.
Думаю, не нужно в сотый раз рассказывать, почему все, кто связан с разработкой сайтов озабочены реализацией мобильной версии. Поэтому предлагаю перейти сразу к разбору способов ее реализации и ускорения.
1. Динамический показ (RESS).
- Рекомендации от Google
- Кратко о способе: Пользователям с мобилок и десктопа показывается разный код по одному и тому же url. Тип устройства определяется сервером.
- Плюсы: Можно сделать дизайн специально под мобилку - содержимое контента для мобилки не обязательно соответствует десктопной версии . Тем более, если вы собираете персонализированные данные у пользователей, то можно показывать им разный релевантный контент.
- Минусы: Очень трудоемко. Требует постоянных обновлений. Сервер не всегда правильно определяет устройство. Значительное увеличение нагрузки на сервер, что не делает загрузку страниц быстрее, а нам важна скорость, не так ли?
- Отношение ПС: Google приемлет, сейчас на многих своих проектах он использует именно этот способ. Яндекс говорит динамическом показе максимально схожим по контенту с десктопной версией.
- Примеры: Saiwala, CNN
2. Мобильный сайт на другом домене
- Рекомендации от Google
- Кратко: просто мобильный сайт на отдельном домене
- Плюсы: Легко отслеживать и отделять мобильную конверсию. Можно разнести на разные серверы. Можно сделать полегче и побыстрее, нежели десктопный вариант.
- Минусы: Отдельный сайт на обслуживании. Все изменения придется вносить отдельно (хотя это может быть и плюсом). Перенаправление пользователя занимает определенное время.
- Как относятся ПС: Яндекс относится нормально, но указывает условие, что структура мобильной версии сайта должна полностью соответствовать структуре основного домена. Google относится нормально
- Примеры: wikipedia.org
3. Адаптивный дизайн.
- Инфа от Google
- Кратко: Контент адаптируется под размер экран
- Плюсы: Адаптируется под большинство экранов. Один сайт проще обслуживать. Не нужно верстать дополнительные страницы. Довольно просто внедрить.
- Минусы: Придется отображать все блоки что есть на десктопе (решение: collapse show с загрузкой по клику. С этим свой вопрос, потому как есть жалобы от иностранных сеошников на индексирование скрытого контента) Нет особой гибкости вариации размещения блоков. Сложнее продумывать варианты ускорения (медленнее загрузка страницы). Как относятся ПС: Яндекс нормально. Google рекомендует использовать именно АВД.
- Примеры: Kiwitaxi
В своем руководстве по оптимизации мобильных устройств Google рекомендует адаптивный веб-дизайн
4. AMP/Турбо
Выделение AMP в поисковой выдаче
- Инфа от ПС: Турбо от Яндекс , AMP от Google
- Кратко: AMP - специальные теги кэшируют информацию на странице и при ее загрузке пользователем эта информация подгружается из CDN Гугла, обеспечиваю высокую скорость загрузки. Турбо - загрузка кэшированной версии страницы на стороне Яндекса.
- Плюсы: Оба варианта имеют свои приоритеты и плюшки в ранжировании. Высокая скорость загрузки страницы. Mobile-friendly. Загрузка происходит на стороне Пс, поэтому нет особой нагрузки на сервер.
- Минусы: Увы, подходят не всем, а только новостным сайтам и каталогам (без фильтров). Для интернет-магазинов есть решение только у Яндекс. Есть свои нюансы со сбором аналитики. Очень малая гибкость.
- Примеры: любые новостные сайты с мобильной версии. Вот lenta подробно описывает опыт внедрения этих страниц:
5. Single Page Application (SPA)
- Инфа от ПС:
- Кратко: Фронтенд грузится на js, поэтому для того, чтобы была успешная индексация, нужно отдавать html снимки роботу.
- Плюсы: Загрузка происходит на стороне пользователя, что равно высокой скорости и низкой нагрузке на сервер
- Минусы: нужно верстать html версии страниц и, когда на сайте происходят изменения, вручную править их. Нужно иметь веб-разработчика в штате. Так же есть вариант реализовывать в spa отдельные особо тяжелые блоки на странице (например результаты поиска) и тогда с html версией будет проще. Я спросила у Платонов, как бы Яндекс отнесся к таким блокам и получила ответ: "Если страницы будут доступны роботу, отвечать на запросы кодом 200 ОК и отдавать контент в HTML-формате, то такие блоки не должны повлиять на индексирование страниц. Они смогут индексироваться и участвовать в поиске в обычном режиме."
- Примеры: mydriver
Ответ техподдержки Яндекс на вопрос о влиянии блока spa на ранжирование в ПС.
6. PWA-приложения
- Инфа от Google
- Кратко: браузер используется как некая виртуальная машина, хранящая и запускающая в себе PWA приложение.
- Плюсы: Надежно (по умолчанию работает только с защищенным соединением), быстро, нативно, способно работать при слабом сигнале или вообще оффлайн, очень гибкий инструмент. Может уведомлять пользователя на мобилках о новостях (push)
- Минусы: как и в SPA нужно иметь html версии страниц. Нужно иметь в штате разработчика приложений. Говорят, Safari пока не поддерживает эту технологию, но эта теория требует проверки.
- Примеры: pwa.rocks
Итоги: У Google очень много решений для реализации мобильных версий сайта, Яндекс старается не отставать в этом плане и внедряет новые продукты. Лично мне особенно интересна версия pwa, как очень гибкий инструмент, не смотря на то, что придется делать маску из html-версии. Для новостных сайтов лучше использовать AMP для Google и Турбо для Яндекса. Отлично подойдет Турбо и для информационных сайтов, и интернет-магазинов. Ну а пока, большинство крупных конкурентов остаются на адаптивной версии сайта, как самой простой и не требующей особенных временных затрат.
Отличные плюсы! Про "перенеправление пользователя": речь идет о прямых заходах или переходах по ссылкам: серверу нужно время, что бы определить, что пользователь зашел именно со смартфона и отправить его на соответствующую версию.
"Дизайн должен минимально отличаться" - да, вы правы, речь о структуре сайта в целом, здесь я эту оговорку исправила. Благодарю.
Отличные плюсы, но есть и минусы: если у вас есть страница на десктопе, но не нет в мобилке - пользователь получает 404. Либо ему отдается обычный вариант десктопной страницы.
Внешние ссылки не полностью передают свой вес. Когда я упомянула, что сайты можно разнести на разные серверы, то имела ввиду и все положительные последствия, в том числе и те, что вы перечислили. Но спасибо, в следующий раз постараюсь подойти более подробно.
Плюсов и минусов для каждого способа гораздо больше, чем я написала в статье. Обратите внимание, что многие крупные коммерческие и информационные сайты перешли именно на адаптив, потому что это легче и дешевле.
При прямых заходах посмотрите в сторону claudflare - они делают это молниеносно, перенаправляя пользователей на вашу мобильную версию практически не ошибаясь.
В больших проектах я использую библиотеку 51Degrees. В бесплатной версии есть все что нужно. Сорцы на гитхабе C / C++ includes PHP, Python, Perl, .NET, Node.js, и Go.
В платной Вы получите полную статистику о мобильном пользователе.
Ps. Один из моих сайтов на данный момент под санкциями РКН. И на время разбирательст, я хотя бы мобильный трафик не потерял, потому что есть мобильная версия на домене 3-го уровня
PWA-приложения - это будущее. С WebAssembly мы сможем создавать программы, которые будут сайтами и сайты, которые будут программами.
А где к "итогам" "SEO-итоги"? Он то же всего один: "3. Адаптивный дизайн".
"Мобильный сайт на другом домене
- Перенаправление пользователя занимает определенное время."
Поисковики уже давно научились в выдаче давать ссылки сразу на мобильную версию.
"Дизайн должен минимально отличаться"
Это кто сказал?
А теперь о плюсах:
1. При ddos есть возможность хоть немного сохранить мобильный трафик.
2. При блокировке дилетантами из РКН домена второго уровня, мобильная версия по адресу m.mysite.com остаётся жива что позволяет см. пункт 1.
А в целом странная статья