11 проверок технического SEO-аудита: что важно, а что не очень?

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

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

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

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

В частности, многие SEO-специалисты делают именно на это акцент. Наша задача на сегодня — разобраться, так ли это, существуют ли проекты без технических ошибок. Рассмотрим e-commerce № 1 в рунете — WildBerries, не будем лезть в дебри, сканировать сайт с помощью краулера, просто посмотрим его главную страницу и посмотрим на его техническое состояние.

У нас есть:

• восемь тегов типа H1-Н6;
• отсутствует какой-либо тег Н-1;
• у них есть пять пустых тегов Н-3;
• нарушена очередность тегов.

То есть техническое состояние сайта нельзя назвать идеальным и «вылизанным». Быть может это какая-то случайность или ситуация наблюдается только на главной странице? Нет, дальше мы видим такую картину.

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

Как обстоят дела с технической оптимизацией

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

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

Что определяет техническая оптимизация

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

То есть поисковый робот должен понимать, о чем структура страниц. Зачем это нужно? Чтобы был проведен корректный расчет факторов ранжирования. Кроме того от технического состояния во многом зависит, какое количество страниц и какие страницы будут включены в индекс поисковой системы, именно по ним будет происходить поиск. И, как итог, некое «честное» ранжирование согласно «честной» релевантности. То есть не какие-то ущербные, плохие позиции, а те, которых мы реально заслуживаем.

Вы можете прописать идеальный robots.txt, настроить страницу 404, сделать sitemap.xml и т.д., это никаким образом не влияет на релевантность страницы поисковому запросу. Это просто устраняет барьеры, которые могут быть у этой страницы для попадания в ТОП. Иногда эти проблемы в результате технических ошибок создаются, а иногда это выносится в некий карго-культ, то есть это делают, несмотря на то, что результатов особенных нет. Исходя из этого, можно выделить некий комплекс работ, который на текущий момент не так важен.

От каких работ можно отказаться

Перечень не обязательных работ, от выполнения которых можно отказаться, выглядит таким образом:

Если мы стремимся к тому, чтобы у нас было стопроцентное соответствие тем условиям, о которых говорит валидатор, валидность разметки документа не дает должного прироста к релевантности, не дает никакого дополнительного барьера, чтобы страница нормально индексировалась, а поисковая система адекватно понимала, какие факторы ранжирования должны быть у данной страницы. Очередность тегов Н1-Н6, как правило, не дает никакого плюса. Единственность Н1, наличие заполненного метатега Keywords, как и метатега description , в конечном счете, конкретно на релевантности не сказываются. Наличие sitemap.xml особенно для небольших сайтов, никаким образом не может улучшить позиции, его отсутствие не является критической ошибкой. Если у вас нет сложностей с индексацией, просто забудьте об этом.

На самом деле, большая часть работ по тех. оптимизации не позволяет решать основную задачу, которая заключается в «не вмешательстве» в работу поискового робота. Он должен включать все страницы в индекс и корректно вычислять зону документа. Если сайт нормально индексируется, страница доступна, то наличие того же sitemap никак не скажется на его ранжировании вообще. Если же сайт плохо проиндексирован, то нужно искать способы подсказать поисковому роботу. Если у вас плотная перелинковка, нет висячих, независимых url или группы url, то есть страниц или групп страниц, попасть на которые можно только в результате введения конкретного адреса в адресную строку, а не по ссылкам, то все окей. Желательно, чтобы таких ситуаций не было.

11 обязательных проверок технического аудита

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

1. Индексация

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

Безусловно, поисковые системы имеют некий основной индекс — то, с чем они работают, документы, с которых они показывают результаты, и дополнительный (скрытый) индекс. В последнем случае речь идет о базе url-адресов, о которых знает поисковая система, она доступна в панели веб-мастера, но они не включены в основной индекс и не участвуют в ранжировании. Это, конечно, основная задача, так как только такие документы могут привлекать поисковый трафик.

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

Полнота индексации

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

У вас есть список url-адресов, которые вы продвигаете, вы хотите их проверить, что они все точно включены в индекс и какой у них возраст. Инструмент проверки «Пиксель Тулс» как раз позволяет это сделать. На самом деле, существуют и другие способы проверки, один из них — Работа в Google Search Console.

Вы загружаете несколько sitemap, желательно, разбивать их по категориями или по типу url-адресов, в результате вы получаете статистику по каждому sitemap, это особенно удобно, если их много. Теперь вы знаете, сколько из url-адресов проиндексировано, какие ошибки были обнаружены, вы можете оценить полноту индексации в рамках категории, типов страниц и т.д. Можно сказать, что это мастхэв вещь для больших сайтов, в том числе, и для интернет-магазинов. В данном случае, sitemap используется не как инструмент повышения позиций, а как инструмент (с помощью Google Search Console), который позволяет отслеживать состояние индексации, то есть решает задачу технической оптимизации.

2. Зеркала и 301-редирект

Проверка номер два — наличие каких-либо зеркал в индексе поисковых систем и 301-редирект на единственное написание доменного имени, который является наиболее основным, его еще называют главным зеркалом в поисковой системе. Проверять доменные имена можно с помощью соответствующего инструментария «Пиксель Тулс» Server Response.

Инструментарий позволяет проверять ваше доменное имя, взять все возможные зеркала, которые вы нашли тоже при помощи инструмента поиска зеркал Пиксель Тулс, и проверить у них код ответа 301 за исключением одной единственной страницы, которая дает код ответа 200 ОК и она является главным зеркалом. Это должна быть версия, к примеру, с https и с www или с https и без www. Все остальные без https и без www должны редиректить на один-единственный URL-адрес, и тогда это будет считаться корректным. Причем, редирект, что важно, должен быть в один шаг. Если редирект происходит в большее количество шагов, что очень часто встречается, когда со старых зеркал ведутся редиректы через несколько шагов, либо с http версии без w, сначала идет редирект на версию с w, а потом только на https и т. д. То есть все возможные вариации в два и больше шагов нужно устранять и обязательно проверять, что все зеркала дают код ответа 301 за исключением одного единственного.

Как искать зеркала и дубли главной страницы? Можно брать уникальный фрагмент с главной страницы либо Title плюс оператор site.

На приведенном примере сайта «СТОЛПЛИТ» — одного из самых крупных сайтов по объему поискового трафика в тематике «мебель», «товары для дома», показано, что можно брать различные сайты, которые привлекают кучу поискового трафика. Кстати, показатели у сайта «СТОЛПЛИТ» достаточно хорошие, ребята хорошо работают. Но на фоне этого у них куча технических косяков — дубли тега Title, поддомены, которые, очевидно, не все нужны в индексе.

Также можно поискать зеркала с помощью нашего инструмента «Поиск зеркал», он позволяет найти зеркала, о которых вы не подозревали или забыли, и проверить сразу код ответа, что удобно. Мы рекомендуем смотреть Яндекс.Метрику точки входа. Когда вы смотрите страницы входа, группируете максимально по домену, проскакивают какие-то технические имена, еще что-то, в идеале, вы должны проверить, что они закрыты от индексации или дают 301-ый код ответа сервера. Ну и помогают анализаторы входящих ссылок типа MegaIndex, target="_blank"Ahrefs, они иногда тоже видят зеркала, о которых вы очевидно не знаете.

3. Битые ссылки внутри сайта

Несмотря на то, что это супер банальная вещь, можем с вероятностью 90% сказать, что у всех читателей данной статьи на сайте есть хотя бы одна битая ссылка. Цель проверки — поиск всех внутренних ссылок, которые ведут на существующие страницы и отдают ответ не 200 ОК. Если хотя бы одна из ссылок, которые есть на вашем сайте, ведут на страницу с кодом ответа 301, 302, 404, 410, 500, 503 — это не очень хорошо.

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

Сделать аудит можно одним из существующих сканеров — Screaming Frog SEO Spider, Netpeak Spider, облачные решения типа seoto.me, который сканирует без загрузки собственного компьютера и покупки специального софта. Предполагаем, что в «Пиксель Тулс» также в ближайшем будущем появится такой сканер для полноценного технического аудита. Если вы также думаете, что его разработка необходима, дайте нам знать об этом и мы повысим приоритетность этой задачи.

4. Проверка аптайма сервера

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

Вы можете посмотреть, как сервер отвечал, когда он последний раз падал, насколько он падал и т.д. На показанном примере можно увидеть, что сайт pixelplus.ru упал 11 сентября на 1 час 13 минут. Хотя аптайм — важная метрика для выбора хостинга и показание для переезда сайта, наличие 503 кода сервера на время падения также учитывается. Если вы планируете технические работы, то вы можете очень легко избавить себя от каких-либо последствий, просто настроив на сервере 503 код ответа.

Тогда поисковая система «зайдет» и увидит, что код ответа корректный, на сайте действительно ведутся технические работы, не будет вам мешать и переиндексировать страницы до тех пор, пока код не сменится на 200 ОК. Когда вы неожиданно «вывешиваете» табличку, предупреждающую о ведущихся тех.работах, страницы попадают, в том числе, и в индекс. На показанном примере видно, что таких страниц довольно много. Здесь многие SEO специалисты разводят руками, ссылаясь на то, что у Яндекса, Google есть крутые механизмы, которые разбираются в понятиях релевантности, ранжировании. При этом вы не научились не включать технические страницы 404, на которых написано: «Я — ошибка 404» (просто отдает ответ 200 ОК), или 503 станица «На сайте ведутся технические работы», продолжая их индексировать. Наверное, поисковой системе сложно разобрать, действительно ли это страница 503.

5. Mobile & Desktop — код

Необходимо проверить совпадение Mobile и Desсtop версии. Понятно, что для мобильной версии оптимальным решением будет адаптивный дизайн.

Если один и то же url-адрес отображается для мобильного и десктопного пользователя, то:

• склеиваются поведенческие факторы;
• сайт хорошо ранжируется;
• удобство сравнения и сканирования данных;
• экономия времени и администрирования.

Есть определенный чек-лист для mobile, которые надо проверять с точки зрения технического состояния:

• проверка на «дружелюбность» каждой страницы для поиска;
• совпадение контента по исходному коду в формате html для мобильного и десктопного пользователя (если вы используете краулер типа Screaming Frog, вы просто меняете user-агента с мобильного на десктопный и сравниваете корректность содержимого);
• ручной просмотр страниц в браузере в мобильном окне;
• оценка поведенческих факторов в Яндекс.Метрике на мобильных устройствах и сравнение с десктопом;
• проверка основных конверсионных элементов;
• проверка скорости загрузки с помощью PageSpeed Insights или инструмента Пиксель Тулс;
• отсутствие горизонтальной прокрутки экрана;
• удобство использования (субъективная оценка).

Ищите качественный софт, в идеале, браузер, который позволяет одновременно просматривать мобильную и десктопную версию сайта, например blisk.io.

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

6. Исключенные url и ошибки

Проверка проводится с помощью Google Search Console и Яндекс.Вебмастера. В результате вы выясните, о чем знает поисковый робот, но что он не включил в основной индекс.

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

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

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

Постоянная претубирация приводит к появлению большого количества выпавших совсем доменов. Мы на вкладке «Конкуренты» в модуле проектов сделали такую сводку, которая позволяет найти отдельную таблицу полностью выпавших доменов. В тематике создания и продвижения сайтов мы видим, что здесь больше десятка таких проектов, которые имели максимальную видимость за период 70%, 30%, 40%, 1 сентября резко выпали. Это акция «Снова в школу», как мы знаем — новый фильтр за накрутку ПФ в Яндексе.

7. Дубль по Title и Н1

Цель проверки — каждая страница имеет уникальный набор тегов Title, Н1, и, желательно, description, который отражает ее суть. Это нужно для того, чтобы поисковая система корректно понимала, чему посвящена страница. Как это происходит?

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

Здесь мы видим куча дублей главной страницы. Это еще одно подтверждение того, что не существует сайтов, на которых нет хотя бы одной технической ошибки. Причем, для примера мы не выбирали сайт долго, взяли первый пришедший на ум, делали проверки, о которых мы сегодня говорим. Если бы для главной страницы был прописан rel="canonical", то всего этого не существовало априори. Дубли главной страницы — это классика поисковой оптимизации.

Мы делаем проверку не только внутри сайта, но и проверяем по результатам выдачи Яндекс, делаем акцент на разводящие страницы — главная, страница каталога, на которой и так много внутренних ссылок, такие страницы часто порождают дубли по ряду причин. Вот очень удобный лайфхак, который, к сожалению, редко используют, но мы хотели бы сделать на нем акцент. Это работа с robots и закрытие всех get параметров в robots с помощью простого правила: Disallow:*?*. Дальше вы открываете только те страницы, с теми get параметрами, которые точно хотите открыть. То есть сначала вы закрываете все, что вы не хотите, чтобы существовало в индексе, дальше открываете только те get параметры, которые нужны.

Либо вы можете вообще удалить страницу с get параметрами, даже для пагинации сделать, допустим, дискет параметров/page2/page3 . Тем самым, вот это правило Disallow:*?* устранит все возможные дубли с get параметрами, которые могут возникать в результате того, что на ваш сайт могут стоять некорректные ссылки, посетители будут заходить на страницы, которых не существует, просто сама поисковая система будет выдумывать какие-то get параметры — такое тоже бывает.

8. Неуникальные блоки текстов

Частый вопрос: «Могут ли неуникальные блоки текстов сайта негативно сказаться на его ранжировании?» На самом деле, да, особенно, если это сквозные куски текста, которые не очень добавляют релевантности странице, в частности какой-нибудь дисклеймер типа «Вся информация, размещенная на этом сайте, является собственностью правообладателя, при копировании…».

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

9. Страница 404-ошибки

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

• Чтобы находить битые ссылки — если вы не настроили существование такой страницы, то с большой долей вероятности вы не сможете корректно и быстро найти ссылки, которые ведут куда-то не туда, они будут отдавать 301, 200 ОК.
• Поисковые системы делают то же самое, что и вы — сканируют сайт, и у них будет возникать аналогичная проблема, они будут включать в индекс те страницы, которые должны отсутствовать. Если у нас ведет битая ссылка на какую-то страницу кода ответа 200 ОК, то такая страница будет, скорее всего, включена в индекс при условии, что будет написано ошибка 404 — страница не найдена.
• Это будет приводить к дублям в индексе и приведет к ухудшению ранжирования, потенциально — дублирование контента внутри сайта;
• В будущем может мешать индексации новых страниц, если на сайте много не ценных страниц, мусора в индексе, то они забирают место.

Что происходит, когда мы настраиваем 301-редирект для всех страниц, которые не существуют? Мы имеем какое-то количество битых ссылок, при этом они редиректят на не главную страницу. При этом, пользователь, который перешел на эту страницу, попал не туда, куда хотел, а перешел на главную, он проходит этот путь заново и все повторяется. Это является проблемой, так как посетитель не может выполнить поставленную задачу, это также мешает поисковым системам корректно понимать, какие страницы нужно включать в индекс, а какие нет. Примеры реальных 404 ошибок:

Здесь отображается Пенсионный Фонд РФ, Рособрнадзор, БиЛайн — не самые плохие сайты, которые удалось найти с помощью нашего Инструмента для массовой проверки кодов состояния (ответа) сервера. Или даже так — на одном и том же сайте включается куча страниц, которые должны отдавать код ответа 404, естественно, они дают 200 ОК, иначе поисковая система их бы не забрала.

То есть, что получается — ошибка 404, но код ответа 200 ОК, поисковая система принимает решение включить эту страницу в индекс, забирая с одного и того же сайта кучу страниц.

10. Индексация поддоменов

Здесь все просто, вы заходите в Инструмент поиска всех поддоменов в индексе Яндекса в «Пиксель Тулс» ссылка и находите все поддомены в индексе.

Вы должны знать, зачем каждый поддомен создан, если о существовании какого-то поддомена вы не подозревали, скорее всего, настраиваете 301-редирект на главную страницу основного сайта. Либо, если она нужна, например, если это def-версия, желательно, закрыть ее под авторизацию, отдаете код ответа не 200 ОК, а 404, чтобы такая страница вообще не индексировалась.

11. Время загрузки url

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

Поговорим о ранжировании. Мы опять взяли тот же ecommerce №1 WildBerries, для примера взяли тег «недорогая обувь» и проверили PageSpeed Insights.

У него показатель 5 из 10, при этом, он находится на первом месте по запросу и в Яндексе и в Google. В реальности так и происходит, скорость и время загрузки для пользователя — некоторая верхушка проблем, она не может слишком сказываться на ранжировании, релевантности документа на текущий момент.

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

Есть исследования, которые говорят, что скорость работы влияет на конверсию, для медленных сайтов ускорение на 1 секунду ведет к росту конверсии на 3% в среднем.

Если ваш сайт грузится до полной загрузки 10 секунд, и вы сделали так, чтобы время сократилось до 9, то конверсия вырастет на 3% от текущего показателя. Например, если сейчас 1%, то станет 1,03%. То есть, это значимый фактор для конверсии, но, с точки зрения, ранжирования, это не особо сказывается.

Один из инструментов оценки скорости и времени загрузки url-адресов, но не единственный — Google PageSpeed Insights.

Мы хоти вас ознакомить с переводом большого исследования, которое вам позволяет сказать, какие cms лучше, хуже отрабатывают, на какие средние показатели вам нужно ориентироваться при оптимизации. При этом важно понимать, что важны не данные, которые показал Google PageSpeed Insights, а данные реальных пользователей. Google Chrome умеет мерить данные при загрузки каждой страницы, каждого пользователя, именно эта информация учитывается непосредственно в ранжировании в отличие от данных Google PageSpeed Insights. К чему следует стремиться с точки зрения скорости загрузки?

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

 Вы настраиваете данный отчет, указываете, что вам нужен:

• Квантиль 90%. Это значит, что у указанного процента пользователей произошло какое-то событие, в данном случае, медленнее или быстрее, чем значение, которое мы ввели. Это же случайная величина, у одного пользователя загрузилось за секунду, у другого — за 10. Конечно, можно усреднить для всех, но это не совсем корректно для статистики, поэтому очень часто используют понятие «квантиль». Берут 90% пользователей и смотрят, какое максимальное время загрузки было у них. Если вы повысите квантиль, например, до 95%, значит, среднее время отрисовки или загрузки страницы сильно увеличится, так как вы сверху добавите 5% самых медленных пользователей. Это достаточно полезная штука, в зависимости от того, какой квантиль вы выставите, будет сильно меняться статистика, к слову, сам Google использует квантиль 90% или 95%.
• Мы смотрим страницы, у которых много просмотров, не единичные загрузки, а хотя бы 100 просмотров. Смотрим время до отрисовки, которое было у 90% пользователей было меньше либо равнялось 90%
• Сортируем все url-адреса по времени убывания параметра «Время до отрисовки», смотрим, какие страницы чаще всего просматривают, и какие из них медленнее всего. Эти страницы — непосредственные кандидаты для оптимизации загрузки.
• Оценка «Ответ сервера» по 50-у квантилю.

На этом первая часть аудита окончена, в следующей части мы рассмотрим такие темы:

Запись вебинара

Чтобы не пропускать новые материалы, подписывайтесь на наши группу ВКонтакте, чат Telegram и канал YouTube.

Вопросы и ответы