Оптимизация для поисковых систем страниц с JavaScript и таблицами стилей


Оглавление (нажмите, чтобы открыть):

Оптимизация для поисковых систем страниц с JavaScript и таблицами стилей — часть 2

А то, что находится на странице ниже, менее важно для поисковой системы.

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

Оптимизация (удаление кода из верхней части страницы, объединение, сжатие) CSS и скриптов, а также настройка загрузки JQuery из Google CDN

Здравствуйте, уважаемые читатели блога Goldbusinessnet.com. Продолжаем подробное изучение возможностей ускорения сайта путем выполнения рекомендаций онлайн сервиса PageSpeed от Гугла, который выдает реальные практические советы по исправлению ошибок.

Я уже писал о реализации сжатия изображений при помощи этого инструмента, теперь на очереди оптимизация CSS и скриптов (javascript), которая может внести серьезную, очень часто даже решающую, добавку в увеличении скорости загрузки страниц сайта.

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

Удаляем код CSS и скрипты из верхней части страницы и объединяем их в один файл

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

Прежде, чем продолжить, хотелось бы сказать вот о чем. Подавляющее большинство владельцев сайтов применяют для своих проектов ЦМС (обзор популярных систем управления контентом). К сожалению, не существует универсальной инструкции для проведения необходимых действий, касающихся абсолютно всех CMS, так как для каждой из них существуют свои тонкости.

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

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

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

Например, на страницах статей Goldbusinessnet.com действует плагин подписки на комментарии Subscribe to Comments Reloaded со своими стилями и скриптами. А в некоторых постах я нередко использую еще и возможности Syntaxhighlighter Evolved, благодаря которому выводятся красивые фрагменты разных кодов с подсветкой.

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

Если раскрыть рекомендацию «Удалите код JavaScript и CSS, блокирующий отображение верхней части страницы» путем нажатия на ссылку «Как исправить?», то можно увидеть более конкретное ее содержание:

Для начала рассмотрим первый совет Пейдж Спид, который касается скриптов, а именно: «Удалите код JavaScript препятствующий отображению»:

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

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

Первые две строчки, касающиеся вывода библиотеки, и третья, отражающая действие скрипта упомянутого выше плагина Subscribe to Comments, как раз необходимы для обеспечения подобного функционала. Поэтому ссылки на эти ресурсы желательно разместить в нижней части HTML кода. Но простым ручным редактированием шаблонов (этот материал предоставит вам информацию о файловом строении темы WP) здесь не обойтись.

Замечу, что ранее Page Speed по результатам анализа частенько выдавал отдельную рекомендацию по объединению скриптов и стилей. Если я правильно понял, сейчас при оценке страницы такой совет отсутствует напрямую, но он, безусловно, подразумевается.

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

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

  • wp_deregister_script, wp_deregister_style — отменяет регистрацию стилей и файлов CSS соответственно;
  • wp_register_script, wp_register_style — регистрирует скрипты и файлы стилей;
  • wp_enqueue_script, wp_enqueue_style — подключает к работе скрипты и CSS.

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

Как настроить загрузку библиотеки JQuery из сети Google CDN

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

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

При этом «ver=1.12.4» означает версию. Интересна вторая ссылка, которая, как вы, наверное, догадались, тоже связана с библиотекой. Это скрипт («jquery-migrate.min.js»), который специально применяется для перехода с устаревших версий и решения проблем несовместимости.

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

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

Если вы помните, на основании итогов анализа PageSpeed необходимо удалить скрипты из области head HTML кода страницы. Для этого в WP есть подходящая функция, которая поможет переместить ссылку в подвал. Кстати, одновременно я решил перенастроить загрузку библиотеки таким образом, чтобы она подгружалась не из папки WP, а из сети CDN самого Гугла.

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

Это решение базировалось на том, что использование CDN (Content Delivery Network или Content Distribution Network — сеть доставки контента) дает ряд преимуществ, а именно:

  • обеспечит передачу JQuery с ближайшего (географически) к вашему компьютеру сервера, что ускорит загрузку;
  • велика вероятность присутствия библиотеки в кеше браузера пользователя, если ранее он уже посещал ваш сайт;
  • файл отдается в сжатом виде, что уменьшает его вес;
  • библиотека будет загружаться в отдельном потоке.

Чтобы осуществить вывод последней версии JQuery CDN Google в соответствии с выше изложенными намерениями, надо отменить регистрацию библиотеки в WP (напоминаю, что мы разбираем оптимизацию применительно к этой ЦМС), а затем перерегистрировать ее с помощью ниже следующей функции, которую нужно прописать в волшебном файле functions.php:

Именно такую конструкцию использовал я при следовании рекомендациям Пейдж Спид. Отключив регистрацию JQuery, мы автоматически отменяем привязку к ней jquery-migrate, после чего в самом низу HTML-кода страницы появится лишь одна ссылка на библиотеку:

Перемещение данного ресурса в подвал обусловлено последним аргументом «true» в строчке регистрации скрипта:

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

Вполне возможно, что свежая модификация библиотеки не будет работать с какими-то скриптами на вашем сайте, тогда попробуйте применять вот такой вариант с указанием нужной версии (естественно, 1.8.3 можно заменить на любую другую):

Даже если структура вашего вебсайта и совокупность действующих скриптов не позволит разместить код вывода внизу HTML-страниц несмотря на наличие атрибута «true», вы все равно добьетесь положительного результата в увеличении скорости сайта за счет того, что библиотека будет подгружаться из сети CDN Гугла.

Отключаем регистрацию стилей и скриптов для их объединения

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

Для минимизации времени загрузки страниц сайта WordPress рекомендуется поместить все скрипты в специально созданный в директории темы файл с расширением .js, а отдельные стили CSS добавить в действующий стилевой файл той же темы style.css.

Для этого веб-ресурса я также создал такой файл (codes.js) для JavaScript, путь до которого прописал в шаблоне footer.php перед закрывающим тегом body (вы можете подсмотреть его в HTML коде в самом низу любой страницы блога, нажав на сочетание клавиш Ctrl + U):

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

SEO-тест: индексация JavaScript-сайтов

JS-сайты и использование js фреймворков в разработке с каждым годом становятся все популярнее. В связи с этим актуальный вопрос для seo-специалистов — влияние js на seo и продвижение сайта. Мы решили провести эксперимент и проверить это в боевых условиях, создав сайты на javascript, а именно на фреймоворке vue js и проверив их индексацию.

Что такое реактивные страницы

Реактивные фреймворки используются для создания реактивных страниц и на данный момент завоевали большую популярность среди разработчиков. Самыми популярными на данный момент являются Angular.js, React.js, Vue.js. У каждого есть свои преимущества и недостатки, но работают они все в принципе одинаково. При загрузке страницы имеется некоторый root элемент (Примечание: root — корневой элемент — то есть элемент, внутри которого будет отрисовываться контент. ), относительно которого рендерится приложение, и содержимое изначальной верстки, например такое

будет отрисовано и превратится в полноценную страницу, между

Проблемы использования реактивных фреймворков

Если просмотреть исходный html-код страницы, которая использует js фреймворк, можно увидеть весь ее изначальный шаблон с разметкой, например:

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

Как поисковики индексируют js

К основным сложностям, связанным с JavaScript, относят:

  • Возможность доступа ботов к информации и анализа контента.
  • Возможность сканирования поисковиками.
  • Задержка загрузки (процесс визуализации веб-страниц).

Первое время поисковики не умели индексировать js. Но уже несколько лет как эта проблема была ими решена. В 2014 году Google объявил, что может «лучше понимать веб (т.е. JavaScript)». В 2015 году Яндекс сообщил в своих новостях: «Мы начали использовать JavaScripts и CSS при обходе некоторых ресурсов для того, чтобы получить больше данных о страницах сайтов и увидеть содержимое таких сайтов в том виде, в каком оно отображается в современном браузере. Это позволяет оценить удобство интерфейса, получить контент, который ранее был недоступен роботу, и сравнить эти данные с уже используемыми при ранжировании в поиске.»

В разделе помощи поисковых систем можно найти информацию, посвященную особенностям индексации. Например, про сайты на ajax Яндекс сообщает: «Робот Яндекса может проиндексировать AJAX-сайт, если у каждой страницы сайта есть HTML-версия.»

AJAX, или «асинхронный JavaScript и XML» — это набор техник по веб-разработке , совмещающий JavaScript и XML, что позволяет веб-приложениям взаимодействовать с сервером в фоновом режиме. Асинхронный означает, что другие функции или линии кода могут запускаться, когда запущен скрипт async. XML некогда был основным языком передачи данных; однако AJAX используется для всех типов передачи данных (включая JSON).

Подготовка к тестированию

При использовании js фреймворка, как правило, используются два варианта получения данных для переменных. Первый — объявить переменные в коде явно, что-то вроде такого:

Зачем покупать товар?

Товар необходимо покупать для.

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

Признаки отсутствия асинхронной загрузки:

Переменные инициализированы в коде, если просмотреть исходный код, то можно увидеть, чему они равны, например

title: ‘Заголовок страницы’, ‘content’: ‘

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

Поэтому мы подготовили два варианта текстов для тестирования, охватывающих оба этих случая.

Проверяем индексацию js сайтов поисковыми системами

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

Для пользователей размещенные тексты на страницах выглядят как обычно. Дополнительно мы разметили заголовок и подзаголовки с тегами h1, h2, h3.Если Вы посмотрите на такие страницы через привычный seo специалистам просмотр кода страницы, то в случае синхронной загрузки Вы увидите текст в коде, а вот в случае асинхронной загрузки — только код без видимого текста.

Советы по технической оптимизации от представителя Google Джона Мюллера рекомендуют тестировать JS-фреймворки с помощью функции Rich Snippets в Search Console и использовать инструмент проверки структурированных данных, чтобы убедиться, что веб-сайт правильно сканируется и отображается.

Аналогично показывает видимость кода страницы и Яндекс Вебмастер.

В Яндекс Вебмастере один из вариантов увидеть страницу как Яндекс — посмотреть на содержимое страницы в Инструменты — Проверка ответа сервера. Здесь при синхронной загрузке видим отображение текста в содержимом. А вот для асинхронной загрузки видим только код.

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

При использовании vue.js заголовок страницы в коде можно указать как

title

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

Реализация проверки seo на vue.js

Таймлайн проверки индексации сайтов поисковиками:

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

В Вебмастере появилось сообщение о добавлении страниц в поиск. Проверяем поисковую выдачу.

По запросу с асинхронной загрузкой по прежнему Яндекс не находит. По запросу с синхронной загрузкой получаем страннный результат — вместо сообщения, что слово не найдено, сообщение, о том, что запросы скрыты в связи с соблюдением законодательства РФ. Делаем скрины, отправляем вопрос поддержке Яндекса.

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

Мы, кстати, не первый раз сталкиваемся с тем, что при первоначальной индексации сайтов робот Яндекса может сделать самые неожиданные выводы,не имеющие с действительностью ничего общего. Решается всё обычно быстро через отправку запроса в поддержку Яндекса.

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

Получен ответ от поддержки Яндекса по выдаче результатов:

Получаем через несколько дней ответ Яндекса:

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

Мастер Йода рекомендует:  Форматируем дату, полученную из БД PHP

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

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


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

Через несколько дней после очередного апдейта в поиске Яндекса появилась и внутренняя страница.

Сниппеты для запросов

С точки зрения seo, нам было также интересно, что используют поисковики в качестве сниппета для нового для них запроса, если не указывать тег description. В текстах мы использовали подзаголвки h1-h3.

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

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

Рекомендации по seo для js

Поисковые роботы не имеют проблем с индексацией js, если выполнены рекомендации (см. ниже). Роботы Яндекса и Google могут проиндексировать сайт с синхронной и с асинхронной загрузкой js.

Рекомендации Google по оптимизации js сайтов, в том числе сайтов на ajax

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

Разрабатывайте сайты на основе принципа доступности. При разработке сайта с применением AJAX подумайте, что нужно пользователям, включая тех, кто не использует браузеры с поддержкой JavaScript (например, людей, работающих с программами чтения с экрана или мобильными устройствами). Один из самых простых способов проверить доступность сайта – предварительно просмотреть его в браузере с отключенной поддержкой JavaScript или в текстовом браузере (например, Lynx). Просмотр сайта в текстовом режиме может также оказаться полезным, если необходимо выявить другое содержание, которое сложно обнаружить роботу Googlebot, например, текст, внедренный в изображения или ролики в формате Flash.

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

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

Если вы начинаете создавать сайт с нуля, бывает полезно построить структуру сайта и систему навигации, используя только HTML. После того как страницы, ссылки и содержание сайта примут упорядоченный вид, можно улучшить внешний вид и интерфейс сайта с помощью AJAX. Робот Googlebot просканирует HTML, тогда как пользователи с современными браузерами смогут оценить ваши дополнения на языке AJAX.При создании ссылок следует выбрать формат, позволяющий наряду с вызовом функции JavaScript предлагать статическую ссылку. Таким образом, пользователи, включившие поддержку JavaScript, смогут применять функциональные возможности AJAX, а те, у кого нет поддержки JavaScript, смогут перейти по ссылке, не обращая внимания на сценарий. Пример.

Обратите внимание, что URL статической ссылки содержит параметр (?foo=32), а не фрагмент ( #foo=32), используемый в коде AJAX. Это важно, поскольку поисковые системы распознают параметры URL, но часто не учитывают наличие фрагментов. Теперь вы применяете статические ссылки, так что пользователи и поисковые системы могут переходить именно к тому содержанию, к которому нужно открыть общий доступ или на которое нужно сослаться.Использование HTML-ссылок по-прежнему значительно помогает нам (а также другим поисковым системам, мобильным устройствам и пользователям) распознать структуру вашего сайта.

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

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

Используйте атрибут rel=»canonical» для указания канонических URL, если контент размещается на нескольких URL-ах.

Избегайте использования AJAX-подобных механизмов сканирования. Это — самая распространенная ошибка, которую допускают специалисты при смене подходов к программированию сайтов. Не забудьте удалять тег «meta fragment» из копии HTML AJAX страниц. Никогда не используйте данный тип тегов, если на странице применяется тег «escaped fragment».

Не используйте в URL-ах символ «#», Google очень редко индексирует такие адреса. Структура «стандартного» адреса страницы должна строиться по принципу: путь/имя файла/параметры запроса, за исключением тех случаев, когда для расширения возможностей навигации используется объект History API.

Чаще применяйте инструмент «Сканер Google для сайтов», доступный в Search Console. Он позволит вам лучше понять, какими видят страницы сайта алгоритмы поискового робота Googlebot. Имейте в виду инструмент не поддерживает URL-ы, содержащие символы «#!» или «#».

Убедитесь в том, что все запрашиваемые ресурсы, включая файлы javascript, фреймворки, ответы сервера, сторонние API и т.д., не закрыты в файле robots.txt. «Сканер Google для сайтов» покажет вам список ресурсов, закрытых от индексации. Если они были закрыты в файле robots.txt (это часто происходит со сторонними API) или временно недоступны по другим причинам, важно дополнительно убедиться в том, что код работает страницы исполняется корректно.

Google поддерживает использование javascript для создания тайтлов, метаописаний и мета-тегов robots, структурированных данных, и других видов мета-данных. Во всех случаях использования формата AMP страница AMP HTML должна быть статической. В то же время, при создании веб-страниц допустимо использовать элементы JS/PWA. Не забывайте создавать файлы sitemap с применением тега тег — это укажет поисковому роботу, что на сайте производились изменения.

Рекомендации Яндекса для Ajax сайтов

Робот Яндекса может проиндексировать AJAX-сайт, если у каждой страницы сайта есть HTML-версия.

Обычно, чтобы указать роботу предпочитаемую для использования в результатах поиска версию, нужно добавить в HTML-код страницы, которая не должна участвовать в поиске, ссылку на нужную страницу с атрибутом rel=»canonical». Этот атрибут может помешать роботу корректно проиндексировать HTML-версию AJAX-страницы, поэтому не используйте его для страниц, которые должны участвовать в поиске.

Вы можете сообщить роботу о HTML-версии страницы с помощью:

Добавьте в код AJAX-страницы метатег meta name=»fragment» content=»!». В итоге HTML-версия этой страницы должна быть доступна по адресу с добавлением параметра ?_escaped_fragment_=(значение параметра пустое).

Не размещайте метатег в HTML-версии страниц сайта — робот не сможет проиндексировать ее.

2) Параметра в адресе страницы

Добавьте в адрес AJAX-страницы параметр #!. В итоге HTML-версия этой страницы должна быть доступна по адресу, в котором сочетание #!заменено на параметр ?_escaped_fragment_=. Например: адрес http://www.example.com/#!blog должен измениться на адрес http://www.example.com/?_escaped_fragment_=blog.

Cсылки, содержащие #!, также можно использовать в карте сайта.

Чтобы робот быстрее узнал о страницах сайта, отправьте на переобход HTML-версии страниц. Когда HTML-страницы появятся в результатах поиска, ссылки будут перенаправлять пользователей на AJAX-страницы сайта.

Дополнительные особенности индексации

Влияние не тестировалось в ходе эксперимента, но можно предположить, что обфускация js не будет влиять на индексацию (теоретически, конечно, могут быть исключения). Обфускация — это приведение исходного текста программы к виду, сохраняющему ее функциональность, но затрудняющему анализ, понимание алгоритмов работы и модификацию при декомпиляции. Цель обфускации js — затруднениe изучения/понимания javascript-кода. JavaScript выполняется на стороне браузера. Даже на довольно старых (более 2х лет назад) форумах можно найти сообщения о том, что поисковики индексируют обфусцированный код.

Сжатие js не влияет на индексацию. Скорее наоборот — это приведет к ускорению загрузки страницы и положительно повлияет на индексирование поисковыми системами. Сжатие js — постоянная рекомендация для сайтов в Google PageSpeed.

Ускорение индексации сайта на js

— лайфхак от Дэвида Кюннена

В январе 2020 года Дэвид Кюннен, специалист из Германии, опубликовал итоги своего тестирования по ускорению индексации сайта на js — «Как добавить 250 тысяч страниц в индексацию Google» («How to get 250k+ pages indexed by Google»). Сайт, о котором речь в статье, был разработан с React App на фронтенде.

В ходе тестирования вначале был настроен SSR — серверный рендеринг. Кюннен исходил из предположения, что рендеринг для SPA-сайтов (Single Page Applications) помогает роблотам сразу видеть все ссылки в коде без двойного прохода по коду. Внедрение рендеринга на сайте позволило ему увеличить скорость обхода страниц Google, но незначительно. В комментариях к публикации также рассматривается альтернатива SSR — использование пререндерера.

Значительного, в несколько раз, увеличения скорости индексирования удалось добиться отключением js для бота.

Поисковик выделяет ограниченное количество ресурсов для индексации конкретного сайта. Несмотря на то, что Google видит все ссылки в начальном HTML, но он все равно отправляет все в свой рендерер, чтобы убедиться, ничего ли не осталось для индексации — из-за наличия в коде JavaScript не понимая, все ли находится в начальном HTML. Сразу же после этих изменений скорость обхода Google увеличилась до 5-10 страниц в секунду.

Итоговая рекомендация от Дэвида Кюннена: Если вы хотите, чтобы Google проиндексировал ваш большой сайт, отдавайте ему сразу финальный HTML, и удалите весь JavaScript (конечно же, за исключением Schema-JS).Подробнее об ускорении js сайтов и о том, не воспримут ли поисковые системы такую отдачу содержимого сайта как манипулирование и подмену информации сайта для поисковиков, относимых к черным методам оптимизации, читайте в нашей статье «Ускорение индексации js сайта».

Оказывается, нет. https://developers.google.com/search/docs/guides/dynamic-rendering В статье Google рекомендует использовать динамическое отображение контента. Оно дает возможность предоставлять некоторым агентам пользователя контент страницы, предварительно обработанный на сервере. Для работы динамического отображения ваш сервер должен распознавать поисковых роботов (например, проверяя агент пользователя). Запросы от роботов передаются средству отображения, а запросы от пользователей обрабатываются обычным образом. При необходимости средство динамического отображения возвращает версию контента, которая может быть обработана роботом, например статическую HTML-страницу.

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

Резюме

Как и ожидалось, Google индексирует и выводит страницы в поисковой выдаче в несколько раз быстрее Яндекса.

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

Страницы js сайтов корректно индексируются поисковыми системами независимо от синхронной или асинхронной загрузки.

На индексацию влияют также корректность чпу и их соответствие правилам поисковых систем.

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

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Оптимизация для поисковых систем страниц с JavaScript и таблицами стилей

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

Нажав кнопку «Принять и продолжить», вы соглашаетесь с Политики конфиденциальности

Мы запустили рейтинг зарплат интернет-маркетологов! Прими участие в анонимном опросе.

How-to – Читать 5 минут – 24 апреля 2020

После нажатия кнопки в нижнем поле появится уменьшенный в размере код. Если включить функции Base 62 encode и Shrink variables, кроме удаления пробелов с комментариями будут меняться переменные с использованием кодирования по технологии Base 62.

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

Еще одним популярным инструментом сокращения кода скриптов считается Closure Complier от Google. Интерфейс сервиса состоит из двух вертикальных полей. Вставлять код JS нужно в левое поле:

Оптимизировать JavaScript с целью сокращения его размера можно вручную и с помощью онлайн-инструментов. Каждая манипуляция по сжатию должна сопровождаться параллельной проверкой страниц сайта.

После удаления пробелов, комментариев, лишних строк замените обычные переменные на их сокращенные версии. Оптимизация кода JS для сайтов на WordРress и других СMS может проводиться с помощью встроенных плагинов.

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

Оптимизация сайта для поисковых систем

Важность планирования нельзя переоценить. Рассмотрим пример базового плана продвижения.

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

Автор достаточно свободно относится к инструментарию и предлагает читателю выбрать его самостоятельно. Это могут быть самые обычные электронные таблицы или же приложения для управления проектами.

Фаза 1. Стратегический план SEO (1 месяц)

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

  1. Отчёт о препятствиях (ОП) поможет вам обнаружить потенциальные проблемы с индексированием сайта поисковиками. Он практически не касается контента и концентрируется на том, насколько полно сайт читаем роботами поисковиков. Среди критериев можно назвать поиск «битых» ссылок и дубликатов контента, анализ карты сайта, оптимизацию файлов robots.txt и .htaccess. Иными словами, здесь важно всё, что должно исключить индексацию ненужных страниц и упростить индексацию нужных. Отчёт может включать данные из Яндекс.Вебмастер или Google Webmaster Tools, а также иных средств базовой аналитики.
  2. Отчёт об анализе конкурентов (ОАК) — это то, с чего надо начинать любое планирование расходов, поскольку критически важно понимать, как много денег и на что тратят компании, которые вы собираетесь потеснить на рынке. Без понимания этого вы рискуете вложить средства в малоперспективный канал продвижения, либо неправильно распределить средства между каналами. Для аналитики можно использовать такие инструменты как Compete.com, SEMRush, KeywordCompetitor и OpenSiteExplorer.org, хотя они не дадут вам оценок по кампаниям, проводимым, скажем, через рекламную сеть Яндекс.
  3. Отчёт об анализе ссылок (ОАС) — достаточно интересная штука. Здесь вам предстоит выяснить, какие каналы продвижения лучше всего работают для вашего бизнеса. Вот лишь некоторые примеры таких каналов: каталоги, региональные блоги, индустриальные порталы, блоги и форумы, блоги экспертов, нишевые социальные сети. Получаемую информацию можно хранить в сервисе Buzzstream, а можно складывать в простую электронную таблицу. В последнем случае стоит пользоваться раздельными страницами таблицы для каждого канала продвижения, иначе управление этим списком со временем существенно усложнится.
  4. Отчёт о ключевых словах (ОКС). Первые три отчёта уже дадут вам достаточно вводной информации по ключевым словам. Диапазон инструментария достаточно широк: здесь пригодится и статистика wordstat.yandex.ru, и отчёты Google AdWords, и Google Insights for Search, и данные по аналитике посещений вашего действующего сайта. Имея под рукой данные по конкурентам, вы можете создать сводную таблицу и выяснить, по каким ключевым словами ваши конкуренты получают больше всего трафика. Вынесите из полученного списка слишком общие и недостаточно популярные термины, отсортируйте результат по релевантности — и вы получите список ключевых слов, с которым можно работать.

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

  1. Переложите данные от ОП в список задач для этапа on-page оптимизации.
  2. Переложите данные по ОАК в электронную таблицу, чтобы её их было легко обновлять.
  3. Переложите данные по классификации из ОАС в один или несколько списков задач для этапа off-page оптимизации; список возможностей переложите в таблицу или Buzzstream.
  4. Перенесите ОКС в электронную таблицу, создайте новую страницу с «говорящим» названием вроде «Мониторинг контента» и скопируйте туда список первой сотни ключевых слов, а затем добавьте столбцы «Название страницы», «Заголовок», «Мета-описание», «Есть ли видео», «Название картинки», «Атрибуты картинки», «Если 500+ слов контента», «Увлекательно ли» и так далее. После этого в системе управления проектами можно расписать и раздать задачи по написанию контента; этот список отправляется на этап on-page оптимизации.

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

Фаза 2. On-page оптимизация (2 месяца)

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

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

Для региональных сайтов и сайтов интернет-магазинов также придётся создать ещё несколько списков задач, которые будут охватывать специфические области оптимизации: трансляцию данных в Яндекс.Маркет, создание региональных страниц приземления и т.д.

Фаза 3. Off-page оптимизация (3-6 месяцев)

Оптимизация сайта под поисковые системы может включать много вариантов; существует огромное количество способов заманить посетителей на сайт. Одним из них является раздача чего-то бесплатного. Буквально в сентябре на SEOmoz была публикация Майкла Эссекса по этой теме («99 Ways to Build Links by Giving Stuff Away»). Изучите все возможные публикации по этой теме, выберите наиболее релевантные вашему бизнесу идеи и добавьте их в список задач SEO в избранной системе управления проектами. Для каждой идеи придётся составить несколько брифов, чтобы идея была понятна и техническим специалистам, и специалистам по маркетингу.

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

Фаза 4. Оптимизация в соцмедиа (1 месяц для начала)

Оптимизированная группа — это группа, которая пользуется популярностью, и на этом этапе начинает возникать немало нюансов. Начните с аудита имеющихся профилей в соцсетях, пройдитесь по описаниям компании, проверьте контактную информацию, формулировки в описаниях (в том числе, на предмет ключевых слов).

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

Фаза 5. Видео и пользователи мобильных устройств (2 месяца для начала)

С технической точки зрения, видеоролики и заходы с мобильных устройств — два отдельных этапа, но это на ваше усмотрение. Что касается видео, здесь есть как сугубо технические задачи (генерирование отдельной карты сайта для видеоконтента), так и коммуникационные (распространение видеороликов по соцсетям). Стоит подумать и о видеорекламе на YouTube. Как показали недавние исследования, Россия лидирует по просмотрам видеороликов в Сети, а российский рынок интернет-видеорекламы по некоторым оценкам к 2020 году вырастет до 280 миллионов долларов. Выводы очевидны.

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

Оптимизация кода страниц или в SEO мелочей нет

SEO-специалистам уже давно известно, что наряду с внешними и внутренними факторами ранжирования сайтов в поисковых системах на позиции в SERP’е влияют и т.н. поведенческие (пользовательские) факторы. Несмотря на это последним уделяют недостаточное внимание. Причин этому множество. Во-первых, не все SEO-компании, особенно занимающиеся «конвейерным» клиентским продвижением, могут выделить ресурсы на анализ влияния поведенческих факторов, мониторинг показателей отказов и количество просмотров страниц, анализ трафика, идущего на сайт и т.д. Во-вторых, специалисты среднего уровня до сих пор работают по принципу «сделал Seo оптимизацию — купил ссылки — жду позиции». В третьих, некоторые оптимизаторы не уделяют внимание пользовательским факторам по той причине, что не считают это нужным, ленятся или просто не знают о них.

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

Зачем это нужно?

Ответ прост. Оптимизация кода не только ускорит загрузку страниц, но и сделает сайт более дружелюбным к поисковым системам — код станет чистым и красивым, а его элементы будут располагаться в нужных местах. Кроме того, изначально скептически воспринятое оптимизаторами в ноябре 2009 заявление Google о том, что скорость загрузки web-документа является одним из факторов ранжирования, только подтверждает тот факт, что оптимизацией кода страниц следует заниматься. Тем более, что на этот фактор оптимизатор может влиять сам.

Мастер Йода рекомендует:  Применение регулярных выражений в PHP, JavaScript, Python, Java

Составляющие оптимизации кода

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

1. Title, Description и Keywords — располагаем сразу после тега .

Данные теги должны следовать сразу после тега . Очень часто этим пренебрегают, и нередко можно видеть, как после заголовка head идёт всё, что угодно, но только не Title и мета-теги. Многие популярные CMS, например, Joomla «грешат» этим.

В приведенном выше примере, если не обращать внимание на спамный keywords, показана часть неоптимизированного поля HEAD.


2. CSS-стили и Java-скрипты — «прячем» в файлы .css и .js.

Если пренебрегать этим простым правилом, то значительную часть кода страницы могут составлять стили оформления элементов страницы и java-скрипты. Этот код является техническим, он не несёт пользователю полезной информации, т.к. в нем не сосредоточен контент, но при этом он добавляет объём для страницы. Поэтому очевидно, что для ускорения загрузки страниц и SEO-вёрстки необходимо выносить его в отдельные файлы с расширениями .css и .js.

3. Контент в коде — «выше»!

Среди вебмастеров ходит много споров на тему того, какая верстка лучше для поисковых систем — табличная или верстка слоями (div’ная). С точки зрения индексации документов отличий никаких нет, однако, табличная верстка не всегда позволяет вывести нужную часть контента вверху кода страницы в отличие от div’ной, где при грамотном с точки зрения SEO-верстки позиционировании блоков можно добиться такого эффекта, что код, содержащий нужный оптимизированный контент, будет расположен вверху. При этом визуально на странице этот блок может располагаться где угодно — как под шапкой, так и в футере сайта. Таким образом, без ущерба дизайну страницы можно добиться дружелюбности к поисковым системам.

4. Ненужный и сомнительный код — закрываем от индексации.

Элементы страниц, не несущие в себе смысловой нагрузки, нужно закрывать от индексации. Таким образом, повышается общая релевантность документа. Яндекс читает код, заключенный в парный тег , но не учитывает его при ранжировании. К ненужному и сомнительному коду можно отнести счетчики статистики (liveinternet, rambler top100, bigmir и т.п.), формы голосований и опросов, отправки заявки или поиска товара, логин-панель и т.д. Встречаются страницы, содержащие все эти элементы. Доля кода SEO-контента на таких страницах будет минимальна.

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

5. Закомментированный код удаляем.

Просматривая исходные коды интернет-страниц, довольно часто можно увидеть закомментированные элементы. Причем иногда суммарная доля такого кода занимает более 50%. Закомментированный код может серьезно увеличить объём html-страницы, тем самым, увеличив время загрузки документа. Такой код может появляться, например, в случае, когда происходит редизайн или переверстка сайта. Верстальщик может закомментировать килобайты кода и не удалить его по окончанию работ.

6. «Скрытые» элементы. Снижение риска наложения санкций.

Если в коде страниц сайта присутствуют скрытые от поисковых систем средствами CSS-форматирования элементы, от них также необходимо избавиться. К наиболее часто встречающимся элементам этой категории относятся «display:none» и «visibility:hidden». Если проект полностью белый и Вам нечего скрывать от пользователей, не стоит рисковать и ждать возможных санкций от Яндекса.

7. Валидность & кроссбраузерность — Яндекс рекомендует.

В своих рекомендациях по созданию сайтов Яндекс отмечает, что код должен быть валидным и соответствовать стандартам W3C. Валидный код гарантированно будет совместим со всеми версиями всех браузеров и обрабатывается лучше, чем код, написанный не по спецификации. Проверить сайт на валидность кода можно на сайте http://validator.w3.org/ .

На поведенческие факторы существенное влияние может оказать некроссбраузерная верстка. Сайт должен одинаково хорошо отображаться во всех современных браузерах при разных разрешениях. Довольно часто можно увидеть, когда браузер Internet Explorer некорректно отображает содержимое сайта, причем отличия с Firefox и Opera кардинальные. Если на таком сайте процент пользователей IE составит 20%, то вероятность того, что показатель отказов значительно увеличится, возрастает. Пользователь не проведет много времени на таком сайте, вероятно, сразу же закроет вкладку и никогда не вернется на сайт повторно. Верстку сайта следует поручать профессионалам, для которых понятия «валидность» и «кроссбраузерность» — не пустые звуки.

8. Оптимизация картинок под web.

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

Выяснялось, что дело не в не самой быстрой скорости подключения к интернету, а в том, что кажущиеся мини-картинки на самом деле имеют огромные разрешения, но вместо того, чтобы сжать изображение в графическом редакторе, верстальщик в коде страницы прописал атрибутам картинок «width» и «height» значения, в 15 раз, меньшие, чем реальное разрешение фотографий. Иногда доходит до того, что в веб-документе используют изображения в формате .bmp, как известно, имеющие гораздо большие объёмы в сравнении с идентичными изображениями в форматах .jpg или .gif. В качестве примера можно привести страницу о популярном сейчас биатлоне — http://magdalena-neuner.narod.ru/nowfoto.html . Чтобы посмотреть в подгружаемом фрейме все фотографии, пользователь вынужден будет скачать порядка 20 Мб трафика, поскольку 90% изображений там выполнено в bmp-формате.

Как быть и что делать в нынешних условиях?

В большинстве случаев, на практике выходит так, что клиент заказывал создание сайта в одной веб-студии или у фрилансеров (к сожалению, данные категории не всегда имеют правильное и современное представление о SEO-верстке), а продвигать решил в одной из SEO-компаний, которые, как правило, такие проблемы не решают и продвигают то, что есть своими «конвейерными» методами. В успешной SEO-кампании в Яндексе в нынешних реалиях мелочей не бывает. Поэтому специалисты, оказывающие профессиональные услуги продвижения сайтов по высококонкурентным запросам обязательно должны иметь в своём арсенале отдел программистов и верстальщиков, а также оказывать и услуги по созданию сайтов. Заказчикам, в свою очередь, желательно ориентироваться на подрядчиков, успешно занимающихся и созданием, и продвижением сайтов одновременно или, как минимум, имеющих хорошую техническую поддержку.

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

Как оптимизировать CSS и JS для более быстрой загрузки сайтов

Дата публикации: 2020-02-06

От автора: для чего нужно оптимизировать CSS и JavaScript? Когда дело касается онлайн-бизнеса, пользовательское восприятие является ключевым фактором. Неважно, ведете ли вы нишевый блог, SaaS сайт или интернет-магазин. Если вы не заботитесь о том, как пользователи воспринимают ваш продукт, не надейтесь, что они когда-либо что-нибудь купят.

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

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

Полная картина с помощью PageSpeed Insights

Чтобы выявить проблемы вашего веб-сайта, которые влияют на скорость загрузки страницы, можно использовать Google PageSpeed Insights. Это бесплатный инструмент, который автоматически сканирует и стационарную, и мобильную версии сайта.

Как создать сайт самому?

Какие технологии и знания необходимы сегодня, чтобы создавать сайты самостоятельно? Узнайте на интенсиве!

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

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

Определить код, который нужно минимизировать

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

При минимизации мы убираем эти лишние символы и тем самым уменьшает траффик и увеличивает скорость загрузки страницы. С помощью PageSpeed Insights вы легко можете определить, какой код нужно минимизировать. Просто нажмите ссылку «Показать, как исправить» и найдите данный ресурс через систему управления контентом (CMS) или через FTP.

Например, если веб-сайт работает на WordPress, тогда весь код должен быть доступен для редактирования в панели «Редактор». Ее можно найти в разделе «Внешний вид» панели администрирования.

Оптимизация кода

Теперь, когда вы определили, какой код нужно минимизировать, пора узнать, как это сделать. Наверное, самый легкий способ минимизировать код – это применить автоматизированные инструменты. Если речь идет о CSS и JavaScript, то наилучшими инструментами для минимизации кода являются CSS Minifier и JSCompress.

Использование CSS Minifier

CSS Minifier – это бесплатный и простой инструмент для сжатия CSS-ресурсов. Все, что вам нужно сделать, это вставить код в поле ввода, задать уровень сжатия и нажать кнопку «Minify».

Процесс минимизации кода может занять от нескольких секунд до минуты, в зависимости от его размера. Новый код можно вставить через интерфейс CMS или FTP.

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

Чтобы проверить, сработала ли минимизация, выполните еще один тест через PageSpeed Insights. CSS файл, который недавно был сжат, не должен больше выдавать сообщение «минимизируйте CSS».

Использование асинхронной загрузки для JavaScript

В отличии от CSS, оптимизация JavaScript выполняется немного сложнее. Перед тем, как пропустить код через JSCompress, нужно сначала рассмотреть вариант асинхронной загрузки кода.

Асинхронную загрузку часто называют «отложенной загрузкой», но, в контексте JavaScript, такой вид загрузки работает посредством функций динамической загрузки.

Чтобы осуществить асинхронную загрузку, просто добавьте тэг async в код вызова .js-файла. Это можно сделать в исходном HTML-коде вашего веб-сайта. Ниже приведен пример того, как это сделать:

Как оптимизировать загрузку js для многостраничных сайтов?

Исходные условия проблемы примерно таковы — есть многостраничный сайт, скажем так «портального» типа, но не очень большой. Бэкэнд традиционно написан на php. На фронтэнде используем jquery со всякими сторонними и своими плагинами для улучшения пользовательского интерфейса — всякие там лайтбоксы, календари, всплывающие подсказки и прочий довольно стандартный зоопарк.

Не так давно нами было решено внедрить модульный подход? асинхронную загрузку с использованием require.js и разделение бэкэнда и фронтэнда. Внедрение прошло удачно, но встал вопрос как теперь оптимизировать загрузку яваскриптов?
Самое популярное решение для require.js, которое предлагается везде, это используя r.js склеить все в один файл и подключать его на продакшене. Но, простите, друзья, для чего мы тогда внедряем всю эту модульность? Только ради удобства в разработке?

У нас в общей сумме на сайте используется около 300-400 кб разного яваскрипта, причем это использование идет совершенно неравномерно по разделам. И мне кажется, что запаковать это все в один файл и отдавать каждому посетителю не совсем правильно. Дело в том, что наш среднестатистический пользователь может никогда не дойдет до страницы или раздела сайта, где мы используем datepicker или загрузку фото, или еще какие-то специфические скрипты. Так зачем мы будем его нагружать этими подарками при первой встрече, заставлять его качать все 400 кб скриптов, а потом заставлять его браузер проводить синтаксический анализ всего этого кода.

Сейчас у нас используется какое-то промежуточное решение, которым мы по прежнему не очень довольны. При первой встрече мы отдаем пользователю минимальный набор необходимых скриптов (100-150 кб), а остальное подтягиваем в виде requirejs модулей. В итоге получаем, что при большом количестве интерактивных элементов на некоторых страницах, в дополнение к базовому набору скриптов у нас запрашивается и качается еще 5-7 javascript файлов. С точки зрения оптимизации, кажется, это тоже не очень красивое решение.

Наверное, не мы первые сталкиваемся с таким вопросом. Сайт у нас не уникальный и проблема тоже.
Что же выгоднее делать с точки зрения правильной клиентской оптимизации:
1. Паковать все скрипты в один файл, отдавать его сразу и не заботиться, что большая часть из этих скриптов не будет востребована многими посетителями сайта?
2. Пытаться как-то поделить скрипты. Отдавать только то, что нужно посетителю на конкретной странице сайта?

Если идти вторым путем, то что делать с оптимизацией? Как быть если страница требует загрузки десятка мелких js модулей?

Требования поисковой оптимизации: вёрстка и разработка сайта

Текст доклада

Поднимем важный вопрос: как разработчикам начать понимать SEO-специалистов? Статья предназначена для разработчиков, верстальщиков, дизайнеров и объясняет, как совместный труд этих специалистов совместно с SEO-специалистами должен работать на общий успех сайта и компании.

Мы разберем основные требования, которые накладывает поисковая оптимизация (SEO) на документы на сайте, а также требования к дизайну, оформлению, CSS, Java Script, поговорим о том, какие основные ошибки допускают верстальщики и как их избежать для того, чтобы не потребовалось в дальнейшем переделывать проект, рассмотрим типичные ошибки при разработке, которые допускают программисты.

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

Тезисы

  1. Базовые требования к документам на сайте.
  2. Требования по дизайну, оформлению, CSS и JS.
  3. Основные ошибки верстальщика.
  4. Типичные недоработки при разработке.
  5. Ошибки программиста.
  6. Технические ошибки, мешающие индексации.
  7. Руководство по первичной настройке сайта.

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

Универсальные требования, которые предъявляются к каждому документу

К таким требованиям относятся наличие и возможность задать уникальные теги Title, meta-тег Description и URL-адрес (с ЧПУ). Эти требования не должны относиться только к избранным страницам, например, к главной, они должны касаться всех страниц на сайте.

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

Размещение уникального текстового заголовка h1 и размещение текста в html-формате

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

Примеры документов, для которых должны удовлетворяться приведённые выше требования:

  • Общие страницы: Контакты, О компании и т.д.
  • Страницы категорий и подкатегорий.
  • Страницы постраничной навигации (пагинации).
  • Детальные страницы (товары, услуги).
  • Страницы тегов, популярных фильтров.
  • Различные языковые версии.

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

Все это нужно для того, чтобы поисковая система и пользователи обращали внимание на информацию на странице и однозначно понимали, зачем эта страница создана, какой потребности пользователя она может отвечать. Задавая в поисковой строке запрос вида [site:domain.ru] — и домен любого из продвигаемых проектов, вы должны наблюдать в выдаче оптимизированные заголовки (длинной в несколько слов из основных продвигаемых поисковых запросов), содержательное описание (Description), уникальное текстовое описание отвечающее потребностям запроса.

Данный поисковый запрос может быть отнесен к разработчику или к владельцу сайта. Вы просто заходите в Яндекс или в Google, набираете поисковый запрос [site:ваш сайт] и смотрите, правда ли все корректно отображается на текущий момент, нет ли там пустых заголовков и подобных недоработок. По умолчанию Яндекс выдает до тысячи результатов, выдачу рекомендуется пролистывать достаточно глубоко.

Требования к дизайну макета

Дизайнер должен отрисовать внешний вид следующих элементов:

  1. Текстовые заголовки h1-h3.
  2. Верстка текста параграфами. Если по умолчанию сверстать их не задав стили CSS, которые задает верстальщик, при сдаче макета, они будут отображаться в разных браузерах абсолютно по-разному, скорее всего, некорректно. Они не будут соответствовать единому оформлению сайта, в итоге SEO-специалисту потребуется снова привлекать дизайнера, который снова отрисует, как это будет выглядеть, и верстальщика для оптимизации под кроссбраузерность. Все это обычно сильно увеличивает сроки получения результатов по продвижению.
  3. Нумерованные и маркированные списки
  4. Дизайн гиперссылок, акцентов в тексте. Можно взять текст по умолчанию, и попросить вашего дизайнера на всех проектах рисовать сразу по умолчанию, как будет выглядеть в верстке макета данный фрагмент текста.
  5. Текстовые ссылки в меню. До сих пор встречаются такие дизайнерские решения, которые невозможно или очень сложно реализовать с помощью обычного текста, верстальщику приходится переходить к созданию картинок, flash-анимации, и так далее.
  6. Масштабирование меню. Дизайнер, отрисовывая меню, должен представлять, как оно будет выглядеть, если увеличить количество пунктов в нем в два раза.
  7. Текстовые заголовки.
  8. Выделить место для размещения текста описания. Объём текста описания должен быть от 800 до 3000 символов, и новый текст будет располагаться на каждой странице. Сегодня по информационным и коммерческим запросам объем текста в 3000 символов может являться избыточным, но небольшое текстовое описание в 800 символов необходимо для нормальной индексации и понимания содержания страницы поисковыми системами.
  9. Сквозные ссылки на основные (продвигаемые) разделы. Если вы точно знаете, зачем создаете ваш сайт, как он будет привлекать аудиторию, какие там будут основные работающие разделы, дизайнер должен предположить, как в один клик с любой страницы попасть на эти разделы. Это требование важно из-за распределения статического веса внутри сайта. Из-за отсутствия сквозных ссылок на основные продвигаемые разделы у поисковых систем могут быть проблемы с пониманием важности этих разделов.
  10. Цепочка навигации. Это один из основных инструментов, помогающих в навигации по сайту.
  11. Иллюстрации. Для детальных страниц товаров и для разбавки текстового блока обязательно размещение иллюстрирующих фотографий.

Рассмотрим примеры классических «косяков»

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

Требования к вёрстке

Можно выделить следующие основные требования к HTML-верстальщику.

Не использовать теги текстовых заголовков h1-h6

Верстка производится с помощью «div», «span» и прочих элементов html, которых вполне достаточно для того чтобы сверстать макет с любыми требованиями. Заголовки используем только исключительно в тексте, только если верстается непосредственно уникальный текст, который размещен на конкретной странице.

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

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

Выносить все стили, которые используются в макете, в отдельные CSS-файлы

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

Все объемные (более 15-20 строк) JS-коды выносятся в отдельные подключаемые файлы

Здесь то же самое, что и с CSS-стилями, исключение могут составить небольшие JS-коды, которые невозможно вынести в отдельные файлы. Также, более лояльно можно относиться к скриптам, размер которых не превышает 15-20 строк.

Использовать единый формат адресов для ссылок

Оптимально — относительные URL вида /catalog/obuv/ со слешем или без него в конце.


Не ставить ссылки на индексные страницы (/index.php)

Добиться кроссбраузерности

На текущий момент по браузерам рунета первое место занимает Google Chrome (более 30%), потом Android, Mobile Safari, Яндекс.Браузер, Firefox, Opera, и в самом хвосте плетется Explorer. Всего лишь 2,5% пользуется Internet Explorer, поэтому можно сказать, что идеальное отображение в нём — это последнее, чего требуется добиваться верстальщику. В первую очередь важны Google Chrome, во вторую очередь мобильные браузеры, за ними идут Яндекс.Браузер и Firefox.

Не допускать конфликта CSS-стилей

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

Мастер Йода рекомендует:  Открытые Linux-бенчмарки для нагрузочного тестирования серверов и веб-приложений

Внешним ссылкам прописывается target=»_blank» — открытие в новой вкладке

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

Основные ошибки верстальщика

Неуместное использование текстовых заголовков h1-h6 для оформления или в качестве оформления логотипа

На иллюстрации пример того, как в текстовый заголовок h1 загоняется ссылка, ведущая на главную страницу, которая в свою очередь является картинкой. Очевидно, что эта конструкция не является главным текстовым заголовком, т.к. это не текст. Это логотип и он должен быть оформлен как div.

Грязный код

Очень часто размер кода Java Script превышает объём полезного содержимого страницы и это говорит поисковой системе о сложности понимания содержимого страницы, где на ней спрятана ценная информация, в большом объеме JS-кода и CSS-стилей.

Битые и «разнообразные» ссылки

Также стоит затронуть вопрос оформления внутренних ссылок в исходном коде и как эти ссылки оформляют HTML-верстальщики.

  • одна ссылка ведет на URL со слешем в конце
  • вторая идёт абсолютная с упоминанием доменного имени
  • далее следует относительная ссылка, но она именно указана относительно данной текущей директории в URL (без слеша в начале)
  • четвертый вариант с указанием ссылки вообще с упоминанием http/https

На деле требуется, чтобы URL-адреса всех ссылок были стандартизированы и указаны как относительные вида /dir/. Это удобно и в случае дальнейшего переезда сайта на другой домен (смене доменного имени).

Не закрытые парные html-теги

Скажем, один из строк

или столбцов

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

Незаданные стили у используемых элементов

По умолчанию у разных браузеров — разные стили оформления, следовательно, будет и различное отображение. На иллюстрации показано, как используется текстовый заголовок h1, в котором должны быть заданы стили. Это такие моменты в оформлении как размер шрифта, его жирность, начертание, отступы, padding и margin. Сам по себе шрифт задан, но если мы будем смотреть его в разных браузерах, для этих тегов будет различное отображение.

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

Ошибки при разработке сайта

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

1) Дублирование текста на страницах, в постраничной навигации, настройках фильтров, вложенных категориях и т.д.

2) Отсутствие возможностей:

  • задать уникальные Title, h1, Description на странице
  • изменить URL с варианта с GET-параметрами на ЧПУ
  • разметить текст на любой странице

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

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

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

  1. Отсутствие отклика сервера в первые 0,2 секунды. Сервер должен сказать — я живой, со мной всё в порядке.
  2. Время загрузки исходного кода страницы. Имеется ввиду не отрисовка браузером самой страницы, а просто скачивание исходного html-кода в том виде, в котором он есть. Процедура должна занимать до 0,7 секунд. Большее время говорит о том, что в дальнейшем время скачивания кода и отрисовки будет некорректно высоко.
  3. Размер кода документа. Размер html должен быть до 120 Кб, потому что больший размер будет долго скачиваться и сложно интерпретироваться.
  4. Аптайм , измерять который рекомендуем либо внутренними инструментами, либо посредством Яндекс.Метрики. По Google Analytics измеряется на очень маленькой выборке, порядка 1% вашей аудитории и поэтому там зачастую наблюдаются очень большие скачки. В Яндекс.Метрике данные корректнее и 99,85% — это минимальный процент времени, в течение которого сервер должен работать.
  5. Негативный пример — когда время отклика 1 секунда. Пользователь может просто успеть уйти. О скорости работы сайта уже очень много раз говорилось, но в данном случае это именно требование SEO, мы не можем достигнуть результатов по продвижению, если оно не выполнено.

Как долгое время загрузки негативно сказывается на репутации вашего сайта можно наблюдать по такому интересному кейсу, как Вконтакте (vk.com). Всем известно, ВКонтакте — один из самых популярных сайтов рунета, и поисковая фраза [вконтакте не работает] и [вк не работает] достигает пика до трехсот тысяч запросов в месяц. В те моменты, когда в 2014 году не работал ВКонтакте, все искали, [почему ВКонтакт не работает], что делать, [как починить ВКонтакте]. Сказался очень большой репутационный эффект. Если до трехсот тысяч пользователей готовы в случае нестабильной работы сайта идти в Яндекс и пытаться найти причину этого, то это очень негативно сказывается на репутации бизнеса.

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

В случае изменения дизайна. Тестовая версия размещается по тестовому адресу закрытой в robots.txt. Cоответственно, тестовая версия изменяется на работающую, код меняется, а robots.txt остаётся полностью закрытым от индексации.

Сайты часто выкатываются в том виде, в каком они есть. Первое, что нужно проверять SEO-специалистам — доступность сайта по большому числу различных зеркал (доменов).

  • Необходимо проверять адреса с «www» или без «www», а также тестовый адрес, который выдается по умолчанию хостерами типа domain.nichost.ru, domain.1gb.ru и т.п.
  • Также нужно проверять, что сайт доступен корректно, отвечает кодом 200 ОК только по одному единственному написанию доменного имени.
  • Не стоит забывать про домены .рф и про https, которые сейчас начали очень активно индексироваться поисковой системой Яндекс. Это большая проблема, т.к. Яндекс подменяет https-результатами обычные результаты выдачи с сохранением позиций и при переходе пользователей из выдачи на эти страницы с https выдается предупреждение о том, что сайт не обладает подтвержденным сертификатом. Пользователь после клика на такую страницу как правило покидает сайт, возвращаясь на выдачу. А это сказывается на поведенческих факторах.

Обязательно проверяйте доступность своего сайта по версии с https! И если она доступна, необходимо поставить редирект с нее на основную версию с http или отключить вообще ее поддержку. Если конечно у вас нет подтвержденного сертификата и если вам не нужна https-версия.

Редирект на новый домен со старого — это тоже серьезная ошибка. Меняя доменное имя, мало просто поставить 301-редирект со старого домена на новый. Таким образом сайт потеряет позиции и трафик из Яндекса примерно на 1.5-2 месяца. Так делать не надо, в нашем разделе «Самостоятельно» имеется инструкция по грамотной смене главного зеркала без опасности для трафика.

Некорректные коды ответа сервера. Нормальный документ должен давать только код 200 ОК, если вы хотите его индексировать, он не должен выдавать другой код. Соответственно, страница, которая отсутствует на сайте, должна выдавать только 404 код ответа сервера и 410 код, если страница удалена окончательно. На нашем сайте также имеется инструкция по настройке правильного кода ответа.

Кто без греха, пусть первый.

Яндекс сам проиндексировал свою же копию главной страницы с https, но не просто с https, а еще с двумя ww: https://ww.yandex.ru, и при этом отдавал нормальный код ответа 200 ОК по этой странице. Проблема этих зеркал куда более актуальна, чем кажется. Она встречается даже на сайтах таких крупных корпораций, как Яндекс.

Постраничная навигация, страница фильтров и сортировка

Постраничная навигация. На странице должна индексироваться постраничная навигация, а URL должен иметь понятный формат. Пример нормального URL: site.ru/dir/page2/, пример ненормального URL — когда к странице постраничной навигации добавляются какие-то GET-параметры. Это очень характерно, например для CMS «Битрикс». URL удлиняется, что сильно мешает индексации страниц. Поисковая система не любит индексировать страницы с длинными URL-адресами, и зачастую плохо их ранжирует, это категорически не нравится SEO-специалистам, а значит, повлечёт дополнительные доработки.

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

Сортировки. Если страницы сортировки доступны для индексации, на них также требуется задавать уникальный Title. В случае, если они запрещены для индексации, ссылки на эти страницы сортировок и должны быть скрыты в исходном коде. Обычно ссылки скрываются с помощью AJAX.

Ошибки при настройке сервера и CRM

Сессионные переменные в URL (типичные примеры: «PHPSESS >

Индексация конфиденциальных данных (в админках и личном кабинете пользователя вида: «/bitrix», «/login», «/admin», «/administrator», «/wp-admin»). Интересный пример — индексация СМС, отправленных компанией Мегафон. Были проиндексированы несколько сотен тысяч СМС, находящихся в открытом доступе, и с помощью Google можно было искать отправленные сообщения.

Некорректная настройка атрибута rel=»canonical» тега link является очень распространенной ошибкой.

Некорректный robots.txt . Все нужные страницы должны быть открыты для индексации.

Отсутствующая карта сайта (sitemap.xml). Карта сайта должна содержать до 50 000 URL-адресов, если все адреса не умещаются в одну, можно сформировать несколько карт. Можно разбивать их на крупные разделы, чтобы лучше контролировать индексацию каждого раздела отдельно.

Не рекомендуется указывать sitemap.xml в robots.txt, лучше указать путь к карте сайта в панели Вебмастера и своевременно обновлять его. Анализируя содержимое карты сайта, различные сторонние краулеры, проверяют на вашем сайте наличие уникального контента, который находится не в индексе поисковых систем, и забирают его себе.

Некорректная работа ошибки 404. Данная проблема ведет к попаданию ненужных страниц в индекс, замусориванию или появлению «бесконечного сайта», в котором календарь событий можно пролистать да, скажем, 2032 года. И все эти страницы будут отдавать код ответа 200 ОК. В результате поисковая система путается и не понимает, какие страницы на сайте нужны, а какие нет. Код ответа должен быть именно 404, а не переадресация на другой URL-адрес, потому что в этом случае теряется возможность вернуться в браузере с помощью кнопки «назад». Страница 404 должна быть оформлена в том же дизайне, что весь сайт, чтобы пользователь не терялся, попав на неё. Не исключается добавление на неё навигации по основным разделам. Также допустим креатив, например, предоставлять клиентам, попавшим на эту страницу, скидки.

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

Пошаговая инструкция, которую рекомендуется усвоить каждому специалисту

Создайте файл robots.txt и настройте его.

Установите 301-редирект на основное зеркало. Основное зеркало указывается в файле robots.txt для Яндекса с помощью директивы «Host:».

Создайте и настройте файл 404-ошибки.

Проверьте корректность работы редиректов и верность кода ответа сервера 404-ошибки (очень часто пишется, что это 404-ошибка, но код ответа у нее почему-то 200 ОК).

Задайте уникальные теги Title для всех страниц (необходимо, чтобы на сайте имелась такая возможность).

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

Настройте ЧПУ для всех или ключевых страниц сайта. Также важно убедиться, что ссылки ведут сразу на конечные URL, не через промежуточные (т.е. сначала на страницу без ЧПУ, а потом через 301-редирект на страницу с ЧПУ; такого быть не должно).

Просканируйте сайт на предмет битых и некорректных ссылок. Устраните их и причину их возникновения.

Просканируйте сайт повторно, убедитесь, что проблема со ссылками решена. Обычно это можно сделать с помощью программы Page Weight, Screaming Frog Seo Spider и аналогичных средств, в том числе онлайн (seoto.me). Пересканировать сайт нужно обязательно, потому что если у вас 404-ошибка была выведена некорректно, повторное сканирование сайта поможет выявить большое число новых ошибок.

Создайте карту сайта sitemap.xml и укажите путь к ней в панелях Вебмастера.

Изучите исходный код основных страниц сайта. Все большие куски JS и CSS должны быть вынесены в отдельные файлы.

Проверьте, что теги h1-h6 используются только как текстовые заголовки, а не элементы дизайна. Для этого нужно проверить, есть ли в исходном коде теги h1-h6 и используются ли они только в тексте.

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

Проведите базовое нагрузочное тестирование — от 10–20 активных пользователей онлайн.

Проверьте валидность кода основных страниц/разделов, устраните самые существенные ошибки.

Проверьте корректность отображения в браузерах Chrome, Android, Safari, Firefox, Яндекс.

Настройте корректное отображение атрибута rel=»canonical» тега link. Это помогает устранить большое количество потенциальных дублей на сайте и сделать доступными для индексации только канонические страницы, которые должны быть проиндексированы.

Настройте заголовок Last-Modified и обработку запроса с условием If-Modified-Since. Когда поисковый робот заходит на ваш сайт и спрашивает, изменился ли данный документ с того времени, когда он последний раз был на нем, если он не изменился, требуется не отдавать исходный код, а дать 304 код ответа и тем самым уменьшить нагрузку на сервер, ускорить индексацию и увеличить её полноту.

Контролируйте аптайм сервера по системам статистики (он должен быть не ниже 99,85%).

Не реже раза в месяц производите контроль индексации — SERP, Вебмастер, сканирование. Это то, что непосредственно относится к обязанностям SEO-специалиста. Нужно не реже раза в месяц просматривать руками, анализировать панель Вебмастера, и производить сканирование и повторное сканирование сайта.

Выводы

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

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

Приведены основные рекомендации по настройке сайта на стартовом этапе и дальнейшему контролю.

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

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

Оптимизация для поисковых систем страниц с JScript и CSS?

Поисковые системы используют ряд критериев, чтобы определить, о чем идет речь на данной веб-странице. Все эти критерии могут быть разными и могут изменяться с течением времени. Они направлены на определение степени «релевантности» страницы, т.е. соответствия данному запросу. Цель поисковой системы — предоставить пользователю результаты, наиболее отвечающие его запросу.

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

Другое мерило соответствия — «плотность ключевых слов». Это отношение количества ключевых слов на странице к общему количеству слов. Чем выше соотношение между ключевыми словами и общим количеством слов, тем больше страница соответствует запросу на эти ключевые слова.

Когда поисковая система отправляет своего робота взглянуть на вашу страницу, вам хотелось бы быть уверенным, что робот найдет нужную информацию в верхней части страницы и что плотность ключевых слов на странице достаточно высока (в пределах разумного). Иногда возникают затруднения, даже если на видном месте вашей страницы расположено достаточное количество текста, насыщенного ключевыми словами. Два таких затруднения — позиционный код JavaScript и позиционный код каскадной таблицы стилей (Style Sheet) — можно легко устранить.

Затруднения с JavaScript

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

Так как поисковые системы склонны обращать больше внимания на текст в начале веб-страницы, чем на последующий текст, очевидно, что наличие нескольких десятков строк кода JavaScript в верхней части страницы отодвигает действительное содержание от начала. А то, что находится на странице ниже, менее важно для поисковой системы.

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

Устранение затруднений с JavaScript

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

Для этого, между заголовочными тэгами Head помещаем следующее ссылку на внешний файл с JavaScript, файл .js:

Обратите внимание, что тег SCRIPT пополнился атрибутом «src». Значение, присвоенное этому атрибуту, — это имя внешнего файла, содержащего код JavaScript. Как правило, такие внешние файлы получают расширение «.js», показывающее, что они содержат код JavaScript. Отметьте также, что здесь присутствуют оба тега , хотя между ними ничего нет. Затем создается новая страница, содержащая код, ранее содержавшийся в тегах SCRIPT.

Затруднения с каскадными таблицами стилей

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

Устранение затруднений со Style Sheet

Идея удаления информации Style Sheet со страницы подобна идее «перегрузки» JavaScript в другой файл; что же касается синтаксиса — имеют местo некоторые отличия.

Мы хотим перенести этот код CSS в отдельный файл, поэтому мы удаляем его с исходной страницы и добавляем ссылку, указывающую на отдельный файл, содержащий теперь код Style Sheet. Как и в случае с JavaScript, между заголовочными тэгами Head помещаем:

Обратите внимание на добавившийся тег LINK. Он содержит информацию трех типов, которая понадобится браузеру для восстановления страницы на время посещения пользователями. Атрибут/пара значений «rel=’stylesheet'» показывает, что мы смотрим на файл Style Sheet. Атрибут/пара значений «href=’style.css'» указывает на внешний файл, содержащий информацию Style Sheet. Типичное расширение этих файлов — «.css», показывающее, что они содержат код Cascading Style Sheet. Вы замените имя файла «style.css» именем файла, в который поместите код Style Sheet. Наконец, нужно определить MIME тип этого файла в атрибуте/паре значений «type=’text/css'». Затем создается новая страница, содержащая код, ранее содержавшийся в тегах STYLE.

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

Здесь может быть Ваша реклама
Место для рекламы

Бесплатный видео курс по созданию собственного мини-сайта

Если Вы не знаете азов HTML.
Если Вы понятия не имеете КАК создаются сайты.
Если Вы не имеете никаких способностей к программированию, —
но собственный мини-сайт Вам нужен позарез, то. выход есть!

Специально для таких, как Вы — абсолютных новичков — был записан и скомпилирован данный видео ряд: 5 бесплатных роликов по программе Macromedia Dreamweaver MX.

Бесплатный видео курс по созданию собственного мега-сайта

Вам нужно создать полностью автоматизированный портал для публикации большого количества материалов, но нет сил на поддержку такого проекта? Ситуация усугубляется тем, что Вы НЕ ЗНАЕТЕ ни одного языка веб-программирования? Выход ЕСТЬ. Воспользуйтесь готовым решением — бесплатным движком, коих в Сети пруд пруди! .. О том «как?» — в данной серии видео уроков.

Добавить комментарий