1. Для SEO консультантов
2. Для веб-разработчиков
3. Основы: что мы знаем о GoogleBot и JavaScript
4. Устаревшая директива Ajax Crawl
5. Динамический рендеринг
6. Принципы создания дружественного поиска фреймворков JavaScript
7. Тестирование вашей реализации
8. Встроенные видимые руководства по SEO для конкретных JS-фреймворков
9. Свяжитесь с нами для получения дополнительной информации

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

Для SEO консультантов

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

Для веб-разработчиков

Если вы разработчик, вы можете обнаружить, что хотите быстрее разобраться в деталях. В каждом из наших руководств для разработчиков мы выступаем за рендеринг на стороне сервера для поисковых систем. К счастью, и React, и Angular 2.0 изначально поддерживают эту функцию, не оставляя больше необходимости в «Директиве Ajax Crawl» или сторонних сервисах предварительного рендеринга . Для получения самых последних инструкций по написанию дружественных для SEO приложений JS, посмотрите это техническое руководство на Angular 2.0 / Универсальный серверный рендеринг или это руководство для ReactJS ,

Фреймворки, такие как Angular и React, набирают популярность на 100-процентных сайтах Builtwith.

Источник изображения: AngularJS Использование (Встроенный) / ReactJS Использование (BuiltWith)

Основы: что мы знаем о GoogleBot и JavaScript

Google продолжает продвигать свои возможности индексации JavaScript. Их сервис веб-рендеринга (WRS) основывается на Chrome 41 , хотя и немного более старая версия Chrome по-прежнему ведет себя как типичный браузер. Несмотря на это, WRS не сохраняет состояние при каждой загрузке страницы, очистке файлов cookie и данных сеанса.

Благодаря нашей собственной работе в области разработки контента JS-фреймворка и некоторого полезного вклада из других источников, мы можем получить некоторые полезные факты о подходе Google к JS, а затем получить представление о нашей технической стратегии SEO:

Робот Google следит за редиректами JavaScript

На самом деле, Google относится к ним очень похоже на 301 с точки зрения индексации. Индексированные URL-адреса заменяются в индексе перенаправленным URL-адресом.

Многое из того, что мы узнаем, получается из тестовых проектов, которые мы создаем в библиотеках, таких как React, но наш опыт основан на работе с командами разработчиков над такими проектами, как красный бык ,

Робот Google будет следовать ссылкам в JavaScript.

Это включает в себя ссылки JavaScript, закодированные с:

• Функции вне пары атрибут-значение href (AVP), но внутри тега («onClick»)
• Функции внутри href AVP («javascript: window.location»)
• Функции вне «а», но вызываемые внутри href AVP («javascript: openlink ()»)

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

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

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

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

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

У Googlebot есть максимальное время ожидания для рендеринга JS, которое вы не должны игнорировать.

В наших тестах мы обнаружили, что контент, который отображался дольше 4 секунд, или контент, который не отображался до тех пор, пока событие не было запущено по ссылке, не находящейся в контейнере «a», не был проиндексирован Google.

Устаревшая директива Ajax Crawl

Схема сканирования AJAX, представленная Google как способ сделать управляемые JavaScript веб-страницы доступными для индексации, наконец, устарела во втором квартале 2018 года , Это должно вызвать несколько сюрпризов, учитывая, что было сделано первое объявление назад в 2015 , но с последующими 3 годами «планирования» это подходит к концу.

Конечно, важно помнить, что Google - не единственная поисковая система, а другие по-прежнему в значительной степени полагаются на это предварительно отредактированное представление, чтобы сканировать и извлекать то, что имеет отношение к делу. Я имею в виду, что даже социальные сети, такие как Twitter и Facebook, используют простой HTML для использования соответствующих мета-тегов.

Эксперимент Бартоша Горалевича обнаружил, что только Google и Ask могут правильно индексировать сгенерированный JavaScript контент:

Google может отображать и сканировать сайты JS. Это, однако, не является гарантией того, что результатом будет оптимизированный для SEO сайт. Техническая экспертиза SEO необходима, особенно во время тестирования. Это гарантирует, что у вас есть SEO дружественная архитектура сайта, ориентированная на правильные ключевые слова. Сайт, который продолжает рейтинг, несмотря на изменения, внесенные в сканировании Google.

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

Динамический рендеринг

Если вы в настоящий момент делаете предварительный рендеринг страниц в Google, вы, вероятно, используете что-то вроде Phantom JS или услуга, такая как prerender.io это позаботится об этом для вас. Оба сценария приводят к статической кэшированной версии страницы, которая эффективно имитирует рендеринг на стороне сервера, без кода, который напрямую влияет на платформу сервера.

Более новые версии Angular ( 4 с универсальным ) и ReactJS имеют возможность рендеринга на стороне сервера , что также приводит к ряду дополнительные преимущества , Переход на последнюю версию был бы идеальным решением для борьбы с устаревшей схемой сканирования AJAX, которая гарантирует, что все поисковые системы, социальные сети и т. Д. Могут последовательно и точно читать контент на вашем сайте.

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

Это маскировка? Нет - точно так же, как когда вы однажды сгенерировали статический снимок своей страницы и доставили его поисковым системам либо через #! или мета-тег, эта страница должна быть идентична странице, сгенерированной JS, чтобы избежать «маскировки». Этот метод точно такой же, но в этом сценарии мы обнаруживаем поисковые системы, а затем обслуживаем одну и ту же статическую страницу и используем только URL-адрес запроса.

Есть нить на эта самая тема в группе Google JavaScript это стоит проверить!

Даже Джон Мюллер решил:

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

Таким образом, если вы не можете сделать ни одного из них, и вы заботитесь о своем SEO , не создавайте PWA !

Принципы создания дружественного поиска фреймворков JavaScript

Рендеринг на стороне сервера

Как мы уже говорили в предыдущем разделе, первое, что я всегда настраивал, это рендеринг на стороне сервера. В Vue.js это означает использование Nuxt.js. В React это означает ReactDOMServer.renderToString (), а затем ReactDOM.hydrate () на клиенте. Угловой 4 имеет Универсальный. Но какую бы технологию вы ни использовали, самое время убедиться, что вы используете универсальный подход, а не предварительный рендеринг, если вы этим занимаетесь в настоящее время.

Это позволяет легко доставлять то, что * должно * отображаться на клиенте, в робот Googlebot и т. Д., И сохранять паритет между ними, как если бы это то, что будет отображаться на клиенте, то же самое и на стороне сервера. Тем не менее, есть кое-что, что может произойти, и это ...

Элементы горячей замены

Вот некоторые распространенные примеры, в которых я вижу, что это проблема:

Галереи изображений

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

Если вам нужно визуализировать каждое изображение, вам придется использовать архитектуру для своих галерей изображений, более схожую с архитектурой, используемой такими вещами, как jQuery (управление тем, что показано с помощью CSS).

Содержание с вкладками

Точно так же, существует тенденция иметь один элемент блока, который меняет содержимое в зависимости от требуемой вкладки, а не с помощью CSS. Опять же, это часто полезно, но это означает, что любой контент, кроме первой вкладки, не будет проиндексирован. Не обязательно проблема, если она очень повторяющаяся или содержит контент, который существует по юридическим причинам / по UX, но вряд ли понадобится более одного раза (например, политика доставки / возврата). Однако, если это требуется для индексации, вы снова используете замененные классы для элементов и CSS для отображения / скрытия объектов.

Содержание, разбитое на страницы

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

Метаданные и маршрутизация

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

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

• заглавие
• Мета-описание
• Rel канонический
• Hreflang rel альтернативный

Ссылки для * Все * Навигация / Доступные URL

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

Что подводит нас к окончательной концепции ...

Притворись JS выключен

Netflix - одно из самых больших имен в сфере React, и многие их знания могут быть применены к любому JS SPA, а не только к React-ориентированным. И самым большим из них является то, что вы должны использовать клиентские библиотеки JS только там, где это действительно необходимо. Я бы сделал большую статью здесь, но, если честно Джейк Арчибальдс это так хорошо, что вы должны просто прочитать его.

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

Тестирование вашей реализации

ползком

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

Сравните необработанный и визуализированный HTML с Screaming Frog

После того, как вам удалось протестировать службу предварительного рендеринга с помощью сканера, вы сразу сможете переключиться в «классический SEO» режим; в том, что вы ищете те же типы проблем, с которыми вы столкнетесь на стандартном / более типичном HTML-сайте.

Вот несколько наших любимых:

Кричащая лягушка - https://www.screamingfrog.co.uk/crawl-javascript-seo/
DeepCrawl - https://www.deepcrawl.com/help/guides/javascript-rendering/
Sitebulb - https://sitebulb.com/resources/guides/how-to-crawl-javascript-websites/
Botify - https://www.botify.com/blog/crawling-javascript-for-technical-seo-audits/

Инструменты Google

Googles Fetch & Render также убегает Chrome 41 и поэтому вы можете либо загрузить и протестировать себя с помощью инструментов разработчика Chrome, либо выполнить запрос через консоль поиска. Возможность взаимодействовать с тем, что на самом деле видит Google, является бесценной информацией для проверки возможности визуализации определенных компонентов.

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

Отключить JavaScript

Особенно полезно при работе с рендерингом на стороне сервера, просто отключив JavaScript в браузере (я предпочитаю делать это через Chrome панель инструментов веб-разработчика но также может быть отключен в Chrome непосредственно ) может быть быстрым способом устранения неполадок компонентов, которые с меньшей вероятностью будут проиндексированы поисковыми системами.

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

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

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

связи

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

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

Встроенные видимые руководства по SEO для конкретных JS-фреймворков

Ресурсы / Дальнейшее чтение

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

Свяжитесь с нами для получения дополнительной информации

контакт

Похожие

Комментарии