Техническая оптимизация

Sitemap.xml: управляем сканированием и индексацией сайта

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

JavaScript SEO: актуальные сведения и практики

Времена, когда сайты были сделаны исключительно на HTML, CSS и PHP давно прошли. Каждый разработчик в 2024 должен уметь писать код на JavaScript, и всё больше сайтов, сделанных на JS-фреймворках. Как это влияет на SEO? – Рассмотрим в этой статье.

Пагинация: разбивка категорий на страницы для SEO

Пагинация – традиционный способ разбивки контента на многостраничный список с присвоением каждой странице условного номера. Так структурируют листинги (списки) товаров, статей, ленты сообщений. Но как настроить пагинацию на пользу SEO?

Протокол HTTP/2 для SEO: преимущества и недостатки

Ваш сайт наверняка давно переехал на безопасный протокол HTTPS, необходимость которого уже несколько лет как анонсировали представители поисковых систем. Но используете ли вы HTTP/2? Что это и почему вам давно пора перейти на этот протокол передачи данных – в этой статье.

Необходимое предисловие

Меня спросят: «Эй, а ты зачем в 2022 году вообще пишешь про HTTP/2, когда на подходе HTTP/3?» – и я скажу вот что. Я регулярно провожу аудиты сайтов, в том числе – в рамках конкурентного анализа. В аудит входит и проверка используемого протокола передачи данных. И увы, вижу, что примерно половина сайтов работает на уже устаревшем протоколе данных, а многие полезные фичи HTTP/2 используются разве что теми, кто использует выделенные сервера.

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

Что происходит во время загрузки сайта

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

• Браузер запрашивает IP заданного домена, обращаясь к серверу доменных имен (DNS). Домен – это просто имя, понятное человеку, а вот IP можно сравнить с телефонным номером этого человека.
• Получив данные об IP сайта, браузер обращается к нему через TCP-соединение через один из стандартных портов: 80-й порт для сайтов без SSL, или через защищенный 443 порт, если настроен HTTPS.
• После подключения браузер отправляет запросы, а сервер отправляет в ответ HTML или перенаправляет на другой URL, или сообщит, что тут такого нету (404).
• Браузер обрабатывает ответ сервера, анализирует полученный HTML и начинает выстраивать объектную модель документа (DOM). В процессе анализа он обнаруживает ссылки на дополнительные ресурсы, которые нужны для правильного отображения страницы, и запрашивает их у сервера. Некоторые из этих ресурсов содержат дополнительные ссылки на другие ресурсы, и эти ссылки добавляются в список запросов.
• Получив достаточный объём этих ресурсов, браузер наконец-то начинает процесс рендеринга страницы, и посетитель сайта (вы) его уже видит. Однако это ещё не конец: браузер продолжает подгружать картинки, вспомогательные скрипты, виджеты и т.п.
• По завершении процесса загрузки браузер запускает событие OnLoad Javascript, страничка готова к работе. Однако и это ещё не конец: страничка может что-то подгружать фоном, отправлять данные в системы статистики и т.д.

Каждая фаза процесса загрузки неравнозначна по времени и важности для посетителя. Статистика утверждает, что большинство пользователей не желает ждать более 4 секунд, а не дождавшись – закрывает вкладку и идёт на другой сайт. И каждая секунда загрузки серьёзно снижает показатели конверсии. Резонно: люди не любят ждать, и люди начинают сомневаться в покупке, если им кажется, что сайт подвисает.

Особенности HTTP ранних версий

Изначально HTTP был простым текстовым протоколом и предназначался только для передачи гипертекстовых документов. Отправил GET-запрос, получил в ответ HTML, ничего лишнего. По мере развития протокола и интернета вообще по этому протоколу стали передаваться и другие типы файлов.

В версии HTTP/1.0 после получения ответа соединение закрывалось, и чтобы отправить другую команду HTTP, соединение нужно было открывать заново. В версии HTTP/1.1 соединение уже оставалось открытым по умолчанию.

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

С появлением метода HEAD клиент мог загружать все метаданные, не загружая сам ресурс. Благодаря этому поисковые системы смогли проверять, обновлялся ли URL, и загружать только обновленные данные.

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

Большим ограничением протокола стала количество одновременно отправляемых запросов, в среднем – 5-8, тогда как среднестатистический сайт уже 10 лет назад редко ограничивался 50-70.

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

HTTPS

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

Протокол HTTPS шифрует передаваемые сообщения с помощью протокола TLS или уже устаревшего SSL. Благодаря HTTPS протокол HTTP получил три важных свойства:

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

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

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

Уровень безопасности данных зависит от типа сертификата, который может быть:

• EV (расширенный сертификат проверки)
• DV (стандартный сертификат проверки домена)
• OV (сертификат проверенной организации)

Но самое важное в контексте этой статьи: протокол HTTPS подразумевает дополнительные запросы и «рукопожатия», ещё более осложняя процесс отправки запросов и загрузки данных.

Основные проблемы HTTP/1

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

В результате развития протокола HTTP стало возможным передавать не только текстовое содержимое, но и мультимедийные файлы, сохранять соединение открытым и отправлять несколько запросов одновременно. Современный сайт загружает около 2,3 МБ данных при отправляемых 70 запросов в целом (фактически, число запросов может доходить до 150 на плохо оптимизированном шаблоне). С учётом того, что современный интернет в большей мере – мобильный, загрузка такого сайта становится слишком долгой.

Проблему можно охарактеризовать несколькими основными моментами:

• Около 80% времени, отводимого на отправку данных, тратится на ожидание передачи этих данных. Эта задержка не связана с пропускной способностью, которая имеет отношение только к максимальному объёму данных, загружаемых пользователем. Количество передаваемых одновременно запросов увеличить нельзя, а само значение задержки определяется физически – это скорость света, проходящего через оптоволоконный кабель.
• Вторая проблема заключается в последовательности запросов к серверу. Для получения ответа на один запрос протокол HTTP блокирует все остальные, пока не завершен один запрос, отправить другой нельзя.

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

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

Как решаются проблемы быстродействия HTTP/1.1

Основными решениями долгие годы были следующие способы оптимизации быстродействия:

• Уменьшение количества запросов благодаря объединению ресурсов (минимизируем CSS и JS, объединяем файлы, вместо отдельных картинок используем CSS-спрайты и т.п.)
• Создание параллельных HTTP-соединений и использование CDN
• Приоритизация списка запросов (сначала – HTML, важнейшие CSS, потом изображения и JS)
• Сжатие используемых ресурсов (в первую очередь – мультимедийных файлов) и использование изображений в сильно «пожатых» веб-форматах
• Передача данных в архивированном виде (gzip)

и т.п.

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

Создание параллельных HTTP-соединений было самым простым. Однако и тут есть ограничение в 4-8 соединений на домен. Чтобы обойти это ограничение, статические ресурсы размещают на CDN (файловом сервере) или на вспомогательном домене, открывающем дополнительные соединения. Благодаря тому, что речь идёт о другом домене (субдомене), браузер видит несколько разных серверов и может обращаться к ним одновременно.

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

Вопросы быстродействия – не единственный недостаток HTTP, и исправлять эти недостатки оказалось разумнее с помощью полного обновления протокола передачи данных. Таким протоколом и стал HTTP/2.

HTTP/2

В 2014 году спецификация HTTP/2 была утверждена как стандарт, а с 2015 года получила поддержку во всех основных браузерах. Новые возможности включали:

• Мультиплексированная асинхронная передача данных: на одном соединении запросы разделяются на чередующиеся пакеты, сгруппированные в отдельные потоки.
• Запросы приоритизируются, благодаря чему снимается проблема с одновременной отправкой всех запросов.
• Реализовано сжатие HTTP-заголовков. Каждый отправленный заголовок содержит информацию об отправителе и получателе, а это – избыточные объёмы. Благодаря сжатию полная информация отправляется только в первом заголовке, в последующих отправленных заголовках такой информации уже нет.
• В отличие от текстового протокола HTTP, HTTP/2 – бинарный. Благодаря этому можно обрабатывать небольшие сообщения, из которых формируются более крупные.
• Server Push. Если в версии HTTP/1 браузер должен был сначала получить домашнюю страницу, и лишь из неё понять, какие ресурсы ему необходимы для рендеринга, то HTTP/2 позволяет отправить все необходимые ресурсы сразу, при первичном обращении к серверу.

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

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

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

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

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

Браузеру уже не нужно составлять очередь из запросов, поскольку все или почти все запросы можно отправить разом (лимит в среднем составляет сотню запросов). Единственный негативный момент: это может привести к снижению пропускной способности, особенно если вы используете неоптимизированные изображения.

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

Преимущества HTTP/2 для SEO

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

Рассмотрим, что именно может стать лучше при переходе на HTTP/2.

• Если вы всерьёз тратили ресурсы (время и деньги) на оптимизацию процессов загрузки – можете расслабиться. Практика показывает, что в среднем одно лишь внедрение HTTP/2 способно улучшить ваши показатели на 50-80% благодаря ликвидации задержки в отправке запросов. Однако надо понимать, что в ряде случаев внедрение HTTP/2 может сказаться и негативно. Эти случаи рассмотрим ниже.
• Отпадает необходимость использования CDN для ускорения загрузки сайта. При достаточной пропускной полосе вы можете загружать быстрее даже «тяжелые» медиа. Однако учитывайте, что CDN полезны не только оптимизацией процессов загрузки за счёт увеличения количества потоков. CDN – это в большей мере про ближайший к вашему посетителю сервер, вопросы безопасности и т.д.
• Упрощается процесс сканирования сайта поисковыми роботами, что критически важно для Google с его лимитами на обход сайта. Известно, что даже при возможности использовать HTTP/2 гуглобот может использовать старый протокол передачи данных (HTTP/1.1), и повлиять на это нельзя. Но если речь идёт о большом и нагруженном сайте, явно стоит предоставить роботу такую возможность.
• Снимается ряд проблем с Core Web Vitals. Браузер сразу получает все критически важные ресурсы, и процесс рендеринга страницы проходит быстрее, более плавно, без необходимости перестраивать блоки по мере получения новой информации о странице. Это, как минимум, должно положительно сказываться на пользовательском опыте: вашему посетителю не придётся чертыхаться, не попав в нужную кнопку или попав в ненужную.
• Поведенческие боты преимущественно используют протокол HTTP/1 и HTTP/1.1. Если вы хотите заблокировать их – обрубайте такой трафик. Учтите, но по этому протоколу могут идти и люди, использующие какие-нибудь дико устаревшие браузеры, но их количество – околонулевое.

Да, возможность использования HTTP/2 не относится к факторам ранжирования и не обещает улучшения позиций. Но его подключение сэкономит вам усилия на оптимизацию быстродействия, улучшит сканирование сайта, а ваши посетители будут иметь меньше проблем при взаимодействии с сайтом. Стоит ли овчинка выделки? – Ответ очевиден.

Возможные проблемы с HTTP/2

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

• В некоторых случаях запросы могут требовать больше времени, если у клиента или сервера низкая пропускная способность. Это может негативно сказываться на подгрузке файлов большого размера и легко объясняется физически. Одно соединение HTTP/2 с малой пропускной способностью потребует больше времени, чем несколько соединений HTTP/1.1 с очередью из нескольких запросов.
• HTTP/2 не устраняет полностью все проблемы своего предшественника: вы просто получаете возможность одновременно отправлять 100 запросов вместо 5-8. По достижении лимита вам так же придётся ждать выполнения первых запросов. Для шаблона сайта, отправляющего 150 запросов к серверу, это ощутимо, просто эффект проявляется реже и чуть слабее. Хотя надо понимать, что для посетителя важнее общее время загрузки, и тут HTTP/2 получает явное преимущество перед HTTP/1.1.
• Если вы уже использовали основные трюки по оптимизации загрузки сайта, прирост скорости загрузки может быть менее заметен. HTTP/2 обеспечивает подобные результаты без серьёзных усилий, состоящих из минификации и объединения файлов, сжатия изображений, искусственного увеличения количества потоков и т.п.

Возможности HTTP/2 не помогут сайтам, размещенным на слабых серверах, и при этом использующим “тяжёлый” код, избыток Javascript, изображения в высоком разрешении, встроенное в iframe видео. Как минимум, переход на HTTP/2 будет полезен, но понадобятся дополнительные настройки, что не всегда возможно, если вы используете виртуальный хостинг, а не выделенный сервер.

Как подключить

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

Протокол поддерживают и nginx актуальных версий (по умолчанию), и Apache (через модуль mod_spdy). Если ваш сервер не поддерживает HTTP/2, можно подключить обратный прокси-сервер с поддержкой протокола. В любом случае, эту задачу должен решать ваш системный администратор, потому что единого рецепта для всех не существует.

Имейте в виду, что подключить HTTP/2 без сертификата SSL не получится: браузеры требуют использования этого протокола только в такой связке, и это логично.

Как проверить, доступен ли ваш сайт по HTTP/2

Как уже было сказано, доступность сайта по HTTP/2 вовсе не означает, что он используется – он вполне уживается с предыдущей версией протокола и не заменяет её. Хорошая метафора в этом случае – это знание двух языков. Если вы знаете русский и английский, к вам могут обратиться и по-русски, и по-английски – это не помешает коммуникациям. Старые и экзотические браузеры будут продолжать обращаться к сайту через устаревший протокол, новые будут использовать HTTP/2.

Чтобы узнать, доступен ли ваш сайт по протоколу HTTP/2, воспользуйтесь одним из следующих способов.

Воспользуйтесь одним из онлайн-сервисов. Их много. Начните с https://http2.pro/

Посмотрите на результаты аудита странички в Lighthouse (Chrome). Если HTTP/2 недоступен, вы увидите соответствующую рекомендацию.

Воспользуйтесь инструментами разработчика в консоли Chrome. В списке ресурсов в колонке “Протокол” они будут помечены как “h2”. (Колонка «Протокол» по умолчанию не отображается. Кликните правой кнопкой по заголовку таблички и поставьте галочку в соответствующей строке).

 

Заключение

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

И не забывайте: веб-технологии не стоят на месте, и уже скоро стандартом станет новый протокол, известный сейчас как QUIC – его чаще всего и называют HTTP/3. Поддержка QUIC в современных браузерах уже есть, но я ни разу не слышал, чтобы виртуальный хостинг в РФ уже предлагал клиентам этот протокол. Кроме того, при нынешней моде на блокировки всего подряд HTTP/3 также попадает под раздачу – но это тема для совершенно других материалов.

Как новый дизайн сайта может повлиять на SEO

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

Тег “Canonical”: что это и зачем

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

Анализ логов сервера для SEO

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

SEO-продвижение сайтов на WordPress

Часто встречается утверждение, что сайты на Wordpress хуже подходят для SEO-продвижения просто потому, что они бесплатны. Это неправда. Сам по себе «голый» Wordpress из коробки действительно не готов для продвижения, и его нужно настраивать и надстраивать. Как это сделать – рассмотрим ниже.

Как настроить “Битрикс” для SEO

1С-Битрикс на сегодня – одна из популярнейших систем управления контентом (CMS). Её используют для создания интернет-магазинов, корпоративных сайтов и даже информационных ресурсов. Поисковая оптимизация сайтов на «Битрикс» имеет ряд особенностей, которые надо обязательно учитывать при проектировании и продвижении сайта.