Как создавать современные индексируемые веб-приложения

Среда, 9 ноября 2016 г.

Современные веб-приложения – это инновационная и многообещающая концепция разработки удобного ПО, которая объединяет в себе преимущества мобильных сайтов и нативных приложений. Но по-настоящему эффективными они будут только в том случае, если их можно будет индексировать, а у их разделов будут ссылки. В этой статье приведены рекомендации, которые позволят вам обеспечить индексирование своих приложений и одинаково применимы как к современным веб-приложениям, так и к статическим сайтам. Мы упорядочили эти советы, чтобы составить для вас удобный контрольный список.

Сделайте контент доступным для сканирования

Зачем? Раньше сайты генерировали или обрабатывали HTML-код на сервере. Это гарантировало постоянный доступ к контенту по ссылкам. С распространением веб-приложений все чаще стала использоваться концепция обработки на стороне клиента: контент динамически обновляется на странице одновременно с действиями пользователя без необходимости обновления страницы.

Наиболее современный подход – гибридная обработка. Когда пользователь переходит по URL в браузере, используется обработка на стороне сервера, а после загрузки первоначальной страницы и для асинхронных запросов используется обработка на стороне клиента.

Мы рассмотрим два примера – одно современное веб-приложение использует обработку только на стороне сервера, а в другом реализован гибридный подход.

Если вы впервые сталкиваетесь с технологиями обработки на стороне сервера и на стороне клиента, ознакомьтесь со статьями об обработке на стороне клиента и сервера и обработке на стороне сервера в решениях на основе React и Node.js.

Что рекомендуется сделать

Используйте гибридную обработку или обработку на стороне сервера, если вам нужно, чтобы пользователи получали контент в первоначальном ответе на запрос.

Убедитесь, что ваши URL общедоступны:

https://www.example.com/product/25/

Ссылка должна указывать на контент на конкретном ресурсе.

Если вы не можете реализовать поддержку гибридной обработки или обработки на стороне сервера в современном веб-приложении и склоняетесь к обработке на стороне клиента, мы рекомендуем с помощью инструмента "Сканер Google для сайтов" в Search Console проверить, может ли поисковый робот Google Поиска сканировать ваш контент.

У пользователей, которые нажали на ссылку на контент в вашем приложении, не должна открываться его главная страница.

Не отображайте страницы ошибок вместо целевых страниц ссылок на контент.


Используйте простые URL

Зачем? Идентификаторы фрагментов (#user/24601/ или #!user/24601/) были эффективным временным решением, позволяющим с помощью AJAX получать в браузерах новый контент от сервера без перезагрузки страницы. Этот способ называется обработкой на стороне клиента.

Однако некоторые веб-инструменты, фреймворки и протоколы (например, протокол Open Graph от Facebook) не поддерживают синтаксис с использованием идентификаторов фрагментов.

History API позволяет обновлять URL без использования идентификаторов фрагментов и при этом асинхронно получать ресурсы, а значит, избегать перезагрузки страниц. Это решение позволяет использовать преимущества обоих указанных выше подходов. Метод на основе AJAX, предполагающий экранирование фрагментов URL с помощью элементов #! и /, когда-то был полезен, но сегодня использовать его не рекомендуется.

Ознакомьтесь с нашими примерами использования History API в гибридных и клиентских современных веб-приложениях.

Что рекомендуется сделать

Используйте простые URL без идентификаторов фрагментов (# или #!), например такие:

    https://www.example.com/product/25/
  

Если вы предпочли гибридную обработку или обработку на стороне клиента, используйте History API для навигации в браузере.

Что не рекомендуется делать

Не используйте элементы #! для создания уникальных URL, например таких:

    https://www.example.com/#!product/25/

Этот способ был временным решением до появления History API и рассматривается как отдельный подход по отношению к стандартному применению элементов #.

Использовать в структуре URL элемент # без символа ! нельзя. Указанный ниже URL не поддерживается:

https://www.example.com/#product/25/

Использование такой структуры URL является особым подходом к созданию сайтов, который предусматривает наличие ссылок на контент на конкретной странице.


Указывайте канонические URL

Зачем? Когда один и тот же контент доступен по нескольким URL (на одном или разных доменах), это может привести к путанице при индексировании. Лучший способ этого избежать – обозначить одну из страниц как каноническую, а все остальные страницы – как дублирующие ее содержание.

Что рекомендуется сделать

Добавьте следующий тег на все страницы, дублирующие определенный контент:

<link rel="canonical"  href="https://www.example.com/your-url/" />

Если вы работаете с AMP-страницами, используйте также инструкцию rel="amphtml".

Что не рекомендуется делать

Нельзя намеренно дублировать контент на нескольких страницах, не помечая одну из них с помощью элемента rel="canonical".

В частности, элементы rel="canonical" помогают избежать противоречий, если вы используете параметры отслеживания в URL.

Следите за тем, чтобы ссылки на канонические страницы не конфликтовали.


Создавайте дизайн, который подходит для разных устройств

Зачем? Ваш сайт должен быть удобным вне зависимости от устройства пользователя.

Мы рекомендуем применять адаптивный дизайн. Он предполагает, что шрифты, отступы, поля, кнопки и прочие элементы изменяются автоматически в соответствии с разрешением экрана и областью просмотра.

Маленькие изображения, растянутые до размеров экрана обычного компьютера или планшета, портят впечатление от просмотра. И наоборот, изображения с очень высоким разрешением не только медленно загружаются, но и усложняют прокрутку страницы на мобильных телефонах.

Подробнее о том, как сделать современное веб-приложение удобным для пользователей

Что рекомендуется сделать

Используйте атрибут srcset, чтобы отправлять изображения разного разрешения для различных устройств и предотвращать загрузку картинок, которые слишком велики для экрана.

Размер шрифта, высота строки, отступы и поля должны быть масштабируемыми и изменяться в соответствии с размерами устройства.

Проверьте, как ваш сайт выглядит при разных разрешениях экрана с помощью режима эмуляции мобильных устройств в инструментах разработчика Chrome и проверки оптимизации для мобильных устройств.

Контент, который вы показываете пользователям, должен совпадать с контентом, который получает Google. Если для показа разных вариантов оформления сайта на различных устройствах вы используете переадресации или определение агента пользователя (также известное как динамический показ), важно, чтобы контент при этом не менялся.

Чтобы проверить, видит ли Google на вашем сайте такое же содержание, что и пользователи, используйте Сканер Google для сайтов в Search Console.

Чтобы сайт был ещё удобнее, не используйте фиксированный размер шрифта.


Используйте итеративный подход

Зачем? При внедрении функций в веб-приложение использовать итеративный подход безопаснее всего. Добавляя по одной функции, вы можете более точно оценивать результаты каждого из таких изменений.

Многие разработчики рассматривают современное веб-приложение как возможность разом переработать весь мобильный сайт и разрабатывают его в изолированной среде, а затем просто заменяют старый сайт новым.

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

Оба подхода имеют свои преимущества и недостатки. Итеративный подход упрощает решение проблем с индексированием, так как переход происходит постепенно. Однако при этом процесс разработки может затянуться, а в результате на сайте могут быть не внедрены некоторые из доступных инновационных решений (если разработка не ведется с нуля).

В любом случае важно следить за каноническими URL и конфигурацией файла robots.txt.

Что рекомендуется сделать

Используйте итеративный подход и внедряйте изменения постепенно.

Например, если у вас ещё не реализована поддержка HTTPS, сначала перейдите на безопасный протокол.

Что не рекомендуется делать

Не публикуйте современное веб-приложение, разработанное в изолированной среде, не проверив URL с атрибутом rel="canonical" и конфигурацию файла robots.txt.

Убедитесь, что ссылки с атрибутом rel="canonical" работают корректно, а конфигурация файла robots.txt позволяет индексировать ваш сайт.

Не забудьте предоставить поисковым роботам доступ к сайту, если вы блокировали его на время разработки.


Расширяйте возможности постепенно

Зачем? Прежде чем задействовать ту или иную функцию, рекомендуется уточнять, поддерживается ли она в браузере. Это надежнее, чем проверять браузер с расчетом на то, что поддержка такой функции в нем заявлена.

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

Service Worker – относительно новая технология, поэтому при работе с ней важно не только стремиться к прогрессу, но и следить за совместимостью. Это хороший пример того, когда уместен принцип постепенного расширения возможностей.

Что рекомендуется сделать

Перед регистрацией Service Worker проверьте доступность его API:

if ('serviceWorker' in navigator) {
...

С помощью API проверяйте, поддерживается ли определенная функция, прежде чем использовать ее.

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

Не публикуйте сайты и не выпускайте для них обновления, не проверив их на различных браузерах. С помощью доступных средств аналитики выясните, какие браузеры популярны у вашей аудитории.


Используйте Google Search Console

Зачем? С помощью этого сервиса вы сможете узнать, как Google воспринимает ваш сайт. Search Console позволяет проверить отдельные URL вашего сайта, а функция "Сканер Google для сайтов" из раздела "Сканирование" покажет, как их воспринимает Google Поиск. При выборе этой функции Search Console обработает ваш код JavaScript и покажет страницу. В противном случае будет показан только необработанный код HTML.

Google Search Console также анализирует содержание страницы на предмет наличия структурированных данных, полезных подсказок, дополнительных ссылок и AMP-страниц.

Что рекомендуется сделать

С помощью Search Console проверьте статус сайта и оцените работу его функций, используя инструмент "Сканер Google для сайтов".

Отправьте в Google файл Sitemap через интерфейс Search Console в разделе Сканирование > Файлы Sitemap. Это эффективный способ проинформировать Google о существовании ваших страниц.


Добавьте структурированные данные от schema.org

Зачем? Структурированные данные, разработанные владельцами сайта schema.org, – это удобная разметка для самого важного контента на ваших страницах, которая позволяет собирать данные алгоритмическим способом. С ее помощью вы можете просто указать, что страница относится к определенной категории (например, NewsArticle), или же отправить в Google более подробные данные о ней. Например, в расписании гастролирующей группы можно указать город, название коллектива, концертную площадку и адрес билетной кассы, а для рецепта – ингредиенты и этапы приготовления блюда.

Метаданные не требуется указывать на всех без исключения страницах сайта, однако в некоторых случаях это может принести немалую пользу. Google извлекает такую информацию после обработки страницы.

Существуют несколько типов структурированных данных, в том числе NewsArticle, Recipe и Product. Ознакомьтесь со всеми поддерживаемыми типами данных.

Что рекомендуется сделать

Убедитесь в правильности указанных на вашем сайте метаданных от schema.org с помощью инструмента проверки структурированных данных.

Проверьте, правильно ли выбран тип данных и нет ли ошибок.

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


Добавьте аннотации Open Graph и Twitter Cards

Зачем? Помимо метаданных jn schema.org, полезно реализовать поддержку протокола Facebook Open Graph и Twitter Cards.

Эти форматы метаданных делают более удобной публикацию вашего контента в упомянутых выше социальных сетях.

Если ваш существующий сайт или веб-приложение использует эти форматы, важно добавить их и в современное веб-приложение, чтобы ваш контент распространялся быстрее.

Что рекомендуется сделать

Проверьте разметку Open Graph с помощью отладчика репостов от Facebook.

Ознакомьтесь с форматом метаданных Твиттера.

Не забудьте включить эти форматы, если ваш сайт их поддерживает.


Тестируйте работу сайта в разных браузерах

Зачем? Для удобства пользователей сайт должен одинаково работать в разных браузерах. Оформление может изменяться в зависимости от размера экрана, но на устройствах одного размера (например, на iPhone и смартфоне Android) принципы взаимодействия с сайтом должны быть одинаковыми.

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

Что рекомендуется сделать

Проверьте свое современное веб-приложение на совместимость с разными браузерами, используя такие инструменты, как BrowserStack.com, Browserling.com или BrowserShots.org.


Измеряйте скорость загрузки страниц

Зачем? Чем быстрее загружается ваш сайт, тем приятнее с ним работать. Оптимизация скорости загрузки страниц является одной из важнейших задач разработчика, о которой многие забывают при создании новой версии сайта.

Работая над современным веб-приложением, оценивайте скорость загрузки страниц и с учетом таких данных оптимизируйте код перед запуском сайта.

Что рекомендуется сделать

Используйте такие инструменты, как Page Speed Insights и Web Page Test для измерения скорости загрузки страниц. Исследования показали, что 40 % пользователей уходят с сайта, который загружается дольше трех секунд.

Подробнее об оптимизации загрузки страниц и процессе визуализации

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


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

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