JavaScript SEO для не-разработчиков

1. Идентификация сайтов, построенных на JavaScript Framework
2. Сканирование сайтов с использованием JavaScript
3. Newsflash: Google все еще отстой в обработке JavaScript
4. Проблемы SEO с JavaScript
5. В чем разница между рендерингом на стороне сервера и на стороне клиента?
6. Что такое Hashbangs и побег фрагменты?
7. Так что же, Hashbangs - ответ на JavaScript Framework SEO?
8. Так в чем же заключается лучшая практика прямо сейчас?

:: Эверетт Сайзмор, наплыв ::

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

SEO должны понимать разницу между рендерингом на стороне сервера (back-end) и на стороне клиента (front-end). Они также должны иметь возможность распознавать сайты, созданные с использованием таких технологий JavaScript, как Angular.js, React.js и Backbone.js. Наконец, оптимизаторы должны понимать основные концепции JavaScript SEO достаточно, чтобы предоставить рекомендации для разработчиков и определить, были ли их рекомендации реализованы должным образом. К концу этой статьи вы должны быть на пути к достижению этих целей.

С 2013 года разработчики внедряют технологию JavaScript в проекты веб-разработки быстрыми темпами, что делает JavaScript SEO более важным, чем когда-либо.

Идентификация сайтов, построенных на JavaScript Framework

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

Возможно, вам нужно знать JavaScript SEO, если ...

За последние несколько лет вы видели страницу с богатым содержанием, содержащую всего несколько строк кода (и без фреймов). Например:

Ты видишь

или то, что выглядит как серверный код в метатегах, а не как фактическое содержимое тега. Например:

Вас попросили оптимизировать сайт с помощью #! (hashbangs) в URL. Например:

www.example.com/page#!key=value

Сканирование сайтов с использованием JavaScript

Если веб-сайт использует хэш-банг в URL-адресе, вы можете сканировать сайт, чтобы получить «URL-адреса», но не содержимое. Чтобы получить содержимое, вам нужно заменить хэш-банг параметром escape-фрагмента с помощью Excel и импортировать этот новый список URL-адресов для нового сканирования. Screamingfrog У инструмента SEO-сканирования есть хорошая функция на вкладке AJAX, которая будет получать HTML-снимок содержимого, если вы будете следовать эти руководящие принципы , Вы также можете сделать это с Глубокий обход , Больше о hashbangs и избежавших фрагментов позже.

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

Newsflash: Google все еще отстой в обработке JavaScript

Google заставил бы разработчиков думать, что JavaScript - это не то, о чем они должны беспокоиться, потому что обо всем позаботятся на стороне Google. Это просто неправда.

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

Менее чем через две недели после того, как Google объявил, что может сканировать JavaScript, и что разработчикам больше не нужно предварительно отображать снимки, чтобы показать их, признал сам Джон Мюллер из Google в конце Веб-мастер Центральная видеовстреча что у них все еще есть проблемы при сканировании Angular.js, и что наилучшее решение (на данный момент) заключается в предварительной визуализации контента для Googlebot.

Проблемы SEO с JavaScript

Хотя Google выполняет JavaScript при сканировании Интернета использование сценариев на стороне клиента для визуализации контента в настоящее время сопряжено с такими проблемами.

# 1 Тот факт, что фрагмент JavaScript может перенести пользователя на другую страницу, не означает, что он аналогичен HTML-ссылке «href» с точки зрения передачи PageRank. Это может объяснить, почему некоторые сайты теряют рейтинги даже при использовании лучших практик для SEO SEO.

window.location.href = "www.mysite.com/page2.php";

[Пример ссылки JavaScript, которая может не передавать pagerank]

# 2 Согласно исследование от Builtvisible Google может прекратить рендеринг контента, если загрузка занимает более четырех секунд, оставляя страницу только частично проиндексированной и кэшированной.

# 3 То же исследование показывает, что контент, требующий «события», может вообще не загружаться. Примеры включают в себя контент, который загружается после нажатия кнопки «еще», карусели изображений или «вкладки» для отображения дополнительной информации о продукте.

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

# 4 Некоторые старые технологии не позволяют универсальный JavaScript где контент может отображаться как на сервере, так и в браузере пользователя. Разработчикам может потребоваться настроить сервер, который использует Phantom.js для визуализации страницы в виде HTML, для использования в сочетании со службой промежуточного программного обеспечения перед рендерингом, такой как Prerender.io а также Brombone предоставлять статические снимки каждой страницы пользователям без поддержки JavaScript, а также поисковым системам.

# 5 Заблокированные ресурсы могут быть большой проблемой для сайтов, загруженных JS. Не блокируйте ресурсы JavaScript в файле robots.txt. Если какой-либо из JavaScript, необходимый для полной визуализации страницы, находится в каталоге, к которому Google не может получить доступ, он не будет отображаться Google, и страница не будет проиндексирована и кэширована с этим контентом.

Очень важно, чтобы робот Googlebot не блокировал выполнение JavaScript, необходимого для отображения контента на странице.

Оптимизаторам приходится иметь дело с дезинформацией от Google о риске «маскировки», когда речь идет об обслуживании предварительно обработанного снимка страницы. Это происходит от этого Google Webmaster Central post в котором Гуглер отвечает на важный вопрос:

Выделенные фрагменты цитируются разработчиками, когда они отсылают к предобработанному контенту в Googlebot.

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

Это то, на что SEO и разработчики должны обращать внимание. Не выделяйте Google. Покажите им тот же снимок, что и другим без JavaScript.

Если вы показываете роботу Google тот же контент, что и пользователям без JavaScript, и это похоже на то, что вы видите с включенным JavaScript, вы не делаете ничего плохого и вряд ли будете «наказаны» за маскировка.

В чем разница между рендерингом на стороне сервера и на стороне клиента?

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

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

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

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

Что такое Hashbangs и побег фрагменты?

Когда разработчики впервые начали использовать AJAX в значительной степени, URL были построены так:

www.domain.com/#page. Внутренние якорные ссылки, подобные этой, используются для пропуска той же страницы, а не для обозначения отдельного URL-адреса для индексации.

Введите решение «hashbang». Выкладываю! перед #, как на www.domain.com/#!page. Это имело два преимущества. Во-первых, он видится поисковыми системами как уникальный URL, а не как переходная ссылка на другую часть страницы. Во-вторых, он делает полный URL-адрес видимым для сервера, что позволяет разработчикам предварительно отображать статический контент на стороне сервера для поисковых систем и пользователей без включенного JavaScript.

Использование #! Формат URL указывает поисковому роботу запросить « сбежавший фрагмент Версия URL. Затем веб-сервер возвращает запрошенный контент в виде HTML-снимка, который затем обрабатывается поисковой системой. Например:

Сканер видит http://www.example.com/page#!content=123

Запросы сканера http://www.example.com/page?_escaped_fragment_=content=123

Сервер возвращает статический, сканируемый «снимок» / page #! Content = 123

Так что же, Hashbangs - ответ на JavaScript Framework SEO?

Ответ: Нет. Есть и другие способы добиться лучшего результата.

Первый способ - это иметь ссылки на контент в HTML, а также перетягивать URL-адрес и направлять его на определенный ресурс на основе этого. Этот метод обрабатывает маршрутизацию так же, как вы это делаете традиционно.

Для примера маршрутизации таким образом, взгляните на проект Пита Уэйлса: https://wail.es/fly-me-to-the-moon/ , Этот сайт использует базовую маршрутизацию в JS для обслуживания разных страниц на основе URL. Это означает, что вы обновляете страницу при смене URL-адреса, так же, как на традиционном веб-сайте.

Другой способ - загрузить вещи через XML Http-запрос (XHR) и обновить URL через API истории HTML5 , Закулисная логика работает так же, как и выше, но обновления URL-адресов происходят с JS, а не посредством реальных изменений страницы. Иди есть посмотрите на этот пример , Нажмите на ссылку и просмотрите изменение URL без обновления страницы.

Так в чем же заключается лучшая практика прямо сейчас?

Все «страницы» должны быть доступны по своему индексируемому URL. Например: http://www.domain.com/page1 ,

Весь важный контент на странице должен быть в полном и окончательном рендеринге HTML. Это может происходить на стороне сервера, или предварительно обработанный снимок (кэш) страницы может быть предоставлен посетителям без поддержки JavaScript и поисковым системам (пока).

инкорпорировать постепенное ухудшение или прогрессивное улучшение концепции, в качестве резервного плана. Включите на странице HTML-навигацию / нумерацию страниц, даже если у пользователя включен JavaScript. Неисправные элементы, такие как карусели изображений, нумерация страниц и содержимое с вкладками, также можно при необходимости поместить в тег «NoScript».

Эверетт Сайзмор является директором по маркетингу в наплыв , маркетинговое агентство электронной коммерции, специализирующееся на SEO, платном поиске и оптимизации конверсии. Он имеет более чем десятилетний опыт работы с электронной коммерцией и является сотрудником Moz. Эверетт рассказывает о техническом SEO на отраслевых мероприятиях, таких как SMX Advanced, SMX Milan, MozTalk и Confluence.

Запросить бесплатную еженедельную рассылку на сайте журнала

Похожие

Комментарии