(Drmax) Аудит Сайта Своими Руками

1
Drmax.su // Аудит сайта своими руками. ч.1. «Технический аудит»
Скачано с сайта https://sharewood.biz/ - Присоединяйся!

2
Аудит сайта своими

руками
Часть I. Технический аудит
http://drmax.su

3
Cодержание
Введение .................................................................................................................................................... 6
1. Подготовка к аудиту .............................................................................................................................. 8
2. Предварительные проверки ............................................................................................................... 13
2.1. Роскомнадзор ............................................................................................................................... 13
2.2. Проверка robots.txt....................................................................................................................... 14
2.2.1. Проверка заблокированных документов в robots.txt ............................................................. 29
2.3. Проверка Sitemap.xml .................................................................................................................. 31
2.3.1. Файл sitemap.xml не указан в файле robots.txt........................................................................ 36
2.3.2. Наличие осиротевших (изолированных) страниц ................................................................... 37
2.4. Использование протокола HTTP/2 .............................................................................................. 38
2.5. Отсутствие переадресации и канонических ссылок с HTTP на HTTPS-страницу ...................... 39
3. Структура сайта, хостовые факторы и URL ......................................................................................... 41
3.1. Анализ уровня вложенности........................................................................................................ 41
3.2. Входящие внутренние ссылки ..................................................................................................... 43
3.3. Анализ 3XX редиректов ................................................................................................................ 44
3.3.1. Цепочки и петли переадресации.............................................................................................. 47
3.3.2. Временная переадресация ....................................................................................................... 48
3.4. Анализ 4XX страниц ...................................................................................................................... 49
3.5. Страницы с кодом состояния 5XX ................................................................................................ 51
3.6. Анализ пагинации на сайте .......................................................................................................... 52
3.7. Слишком длинный URL ................................................................................................................ 56
3.8. Символ подчеркивания в URL ...................................................................................................... 57
3.9. Слишком много параметров в URL .............................................................................................. 58
4. Анализ HTML кода, тегов и метатегов ................................................................................................ 59
4.1. Страницы с избытком внутренних ссылок .................................................................................. 59
4.2. Страницы с избытком внешних ссылок ...................................................................................... 60
4.3. Нерабочие внешние ссылки ........................................................................................................ 61
4.4. Страницы без тега Title ................................................................................................................. 63
4.5. Страницы c дублирующимися тегами Title ................................................................................. 65
4.6. Страницы c совпадающими тегами Title и H1 ............................................................................ 67
4.7. Страницы c несколькими тегами Title ......................................................................................... 68
4.8. Излишне длинные/короткие теги Title ....................................................................................... 69
4.9. Отсутствует описание страницы (метатег Description) ............................................................... 72

4
4.10. Дублирование метатега Description .......................................................................................... 74

4.11. Использование нескольких метатегов Description на странице ............................................. 75
4.12. Использование излишне коротких/длинных метаописаний .................................................. 76
4.13. Страницы без тега H1 ................................................................................................................. 77
4.14. Дублирующиеся H1 в пределах сайта ....................................................................................... 78
4.15. Несколько H1 в пределах страницы .......................................................................................... 79
4.16. Проверка метатега viewport...................................................................................................... 80
4.17. Проверка lang и hreflang ............................................................................................................ 81
4.18. Проверка кодировки .................................................................................................................. 82
4.19. Проверка типа документа .......................................................................................................... 83
4.20. Нерабочая каноническая ссылка ............................................................................................... 84
5.Анализ контента ................................................................................................................................... 86
5.1. Поиск низкоуникальных страниц в пределах сайта ................................................................... 86
5.2. Страницы с малым содержанием контента (Thin Content) ....................................................... 89
5.3. Страницы с низким соотношением контента к коду.................................................................. 90
5.4. Flash элементы .............................................................................................................................. 91
5.5. Смешанный контент ..................................................................................................................... 93
6. Анализ проблемных страниц .............................................................................................................. 94
6.1. Страницы с высоким процентом отказов ................................................................................... 94
6.2. Страницы, отсутствующие в органической выдаче .................................................................... 95
6.3. Страницы с низким CTR ................................................................................................................ 96
6.4. Страницы с малым временем просмотра................................................................................... 97
6.5. Страницы с большим временем загрузки .................................................................................. 98
7. Проверка изображений .................................................................................................................... 101
7.1. Поиск неработающих изображений ......................................................................................... 101
7.2. Изображения без alt тега ........................................................................................................... 103
7.3. Поиск неоптимизированных изображений .............................................................................. 105
8. Кейс: Скорость загрузки страниц сайта ............................................................................................ 107
8.1. Оценка производительности страниц сайта ............................................................................. 110
8.2. Группа показателей Cache policy ............................................................................................... 114
8.3. Группа показателей Number of requests ................................................................................... 116
8.4. Группа показателей Security ...................................................................................................... 120
8.5. Группа показателей Accessibility ................................................................................................ 123
8.6. Группа показателей Compliance ................................................................................................ 126
8.6. Группа показателей Quality ........................................................................................................ 128

6
Введение
На сегодняшний день существует уже более двух тысяч факторов

ранжирования и их самых причудливых сочетаний.
По значимости, примерно 30-40% занимает группа ссылочных

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

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

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

приведенных технических факторов. Аудит, хоть и займет довольно
продолжительное время, но улучшение технического состояния сайта
благотворно скажется на его ранжировании. Конечно не стоит забывать и о
иных методах продвижения – линкбилдинг, обновление сайта, работа с
поведенческими факторами, продвижение мобильной версии и пр.
Желаю Вам удачи!
Ваш DrMax
июль,2018

7
Другие мои книги:
SEO Монстр 2018.

Руководство по глобальному
продвижению сайтов
http://drmax.su/seo-monstr-2018.html
SEO Гуру 2018.

Руководство по мобильному и
Региональному продвижению
http://drmax.su/seoguru-2018.html
Если Вам необходим профессиональный аудит сайта,

консультации по продвижению сайта, то обращайтесь.
Помогу и проконсультирую.
http://drmax.su/audit-i-seo-konsultirovanie

8
1. Подготовка к аудиту
Перед проведением аудита необходимо максимально снизить влияние

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

CCleaner: http://www.ccleaner.com/ru-ru
Здесь можно настроить какие куки следует удалять, а какие добавить в

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

9
Следующим шагом осуществляем настройку Screaming Frog – нашей

основной программы для проведения аудита:
https://www.screamingfrog.co.uk/seo-spider/
Программа бесплатна для аудита сайтов до 500 URI включительно.

Желательно использовать последнюю, актуальную, зарегистрированную
версию.
Для начала настроим краулер (паука)программы.
На закладке основных настроек устанавливаем значения следующим

образом:

10
На закладке «Reendering» мы выбираем как краулер (паук) программы

будет обходится с Java скриптами – будет ли он пытаться на лету выполнить
их, попытается ли вычислить ссылки, генерируемые скриптами (например
какие то фильтры или меню в вашем интернет магазине) и пр.

11
Необходимо отметить, что Google с весны 2018 года умеет разбирать и

анализировать практически все виды Java скриптов:
В то же время, Яндекс не может сканировать и индексировать

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

«Text Only».

12
Далее подключаемся к API Google Analytics и Google Search Console для

анализируемого сайта. Убедитесь предварительно, что вы добавили свой
сайт в интерфейсах этих систем:
На этом подготовка завершена. Запускайте краулер кнопкой «Start».

13
2. Предварительные проверки
2.1. Роскомнадзор
В последнее время я начинаю любой технический аудит с проверки

блокировки российскими регуляторами интернета. Если вас не интересует
трафик с России, то пропустите данный этап проверки.
Проверьте «забаненность» (блокировку) вашего сайта по IP и

доменному имени здесь:
https://eais.rkn.gov.ru/
и здесь:
https://antizapret.info/
Обратите внимание, что использование платных, а уж тем более

«бесплатных» CDN достаточно опасно в России. Их использует множество
«грязных» сайтов, типа адалта и пр, которые с блокирует Роскомнадзор и
прочие цензоры интернета. Зачастую они блокируют не только доменное
имя, но и IP, т.е. банят один из адресов CDN (или сразу группу адресов), со
всеми хостящимися на ней сайтами.
CDN, как правило, блокируют по диапазонам адресов, поэтому

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

провайдеров: https://ping-admin.ru/free_test/

14
2.2. Проверка robots.txt
Убедитесь, что у вашего сайта есть robots.txt и он настроен корректно.
Если файл robots.txt написан с ошибками, это может привести к

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

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

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

бота ПС на нужные страницы, не разрешая создавать дубли контента,
приводящие к понижению позиций.
Файл robots.txt должен:
 располагаться строго в корне сайта,

 он должен быть единственным,

15
 число директив (команд) не должно превышать 1024,

 размер не превышать 500kB (для Google).
В соответствии со стандартом перед каждой директивой User-agent

рекомендуется вставлять пустой перевод строки.
Символ # предназначен для описания комментариев. Все, что

находится после этого символа и до первого перевода строки не
учитывается.
Если файл robots.txt отсутствует, не является текстовым или на запрос

робота возвращается HTTP-статус отличный от 200 OK, робот считает, что
доступ к документам не ограничен и можно индексировать все в пределах
сайта.
Robots.txt должен содержать обычный текст в кодировке UTF-8,

состоящий из записей (строк), разделенных символами возврата каретки,
возврата каретки/перевода строки или перевода строки.
Выполняются только действительные записи, остальное содержание

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

входящие в таблицу UTF-8, синтаксический анализ содержания файла может
быть выполнен неправильно.
Отметка последовательности байтов (BOM) в начале файла robots.txt

игнорируется. Добавлять ее не обязательно.
Файл состоит из одной или нескольких директив User-agent, которые

предназначены для описания директив для разных роботов, директив

16
Disallow и Allow, которые служат для запрета или разрешения индексации и

межсекционной директивы sitemap.
Яндекс ранее использовал директиву host, которая ранее указывала на

главное зеркало сайта, а ныне не используется. Также Яндекс изобрел
директиву Clean-param, которая служит для очистки динамических
параметров урла и снижения нагрузки на хостинг.
Директива Disalow служит для запрета индексации, Allow – для

разрешения индексации.
Каждая запись состоит из поля, двоеточия и значения. Использование

пробелов не обязательно, но рекомендуется для удобства чтения.
Комментарии могут размещаться в любом месте файла и должны
обозначаться символом #. Все содержание, расположенное после этого
знака до конца строки, расценивается как комментарий и игнорируется.
Общий формат: <поле>:<значение><#комментарий (не обязательно)>.
Пробелы в начале и конце записи игнорируются.
Для элемента <поле> регистр не учитывается. Элемент <значение>

может быть чувствительным к регистру (в зависимости от элемента <поле>).
Обработка элементов <поле> с простыми ошибками или опечатками

(useragent вместо user-agent и т. п.) не описана. Некоторые агенты
пользователя обрабатывают такие ошибки правильно.

17
Закрыть страницы сайта от индексирования можно несколькими

способами, в том числе прописать метатег robots, где можно указать
следующие директивы (в нотации для Google):
 all – Нет ограничений на индексирование и показ контента. Эта

директива используется по умолчанию и не влияет на работу
поисковых роботов, если нет других указаний.
 noindex – Не отображать эту страницу, а также ссылку
«Сохраненная копия» в результатах поиска.
 nofollow – Не выполнять переход по ссылкам на этой странице.
 none – Аналогично метатегам noindex, nofollow.
 noarchive – Не отображать ссылку “Сохраненная копия” в
результатах поиска.
 nosnippet – Не отображать расширенное описание этой веб-
страницы в результатах поиска.
 notranslate – Не предлагать перевод этой страницы в результатах
поиска.
 noimageindex – Не индексировать изображения на этой странице.
 unavailable_after: [RFC-850 date/time] – Не отображать эту
страницу в результатах поиска после указанного времени/даты.
Время/дату следует указать в формате RFC 850.
Очень часто возникают противоречия между директивами в robots.txt

и метатегом на странице. Например, в robots.txt страница закрыта для
индексирования, а метатегом robots страница открыта для индексации. Что
происходит в этом случае?
Для Google выполняется такое правило: «метатеги robots

обнаруживаются при сканировании URL. Если сканирование страницы
запрещено файлом robots.txt, то директивы, касающиеся индексирования

18
или показа контента, будут проигнорированы. Чтобы обеспечить

обязательное выполнение директив, не следует запрещать сканирование
URL, для которых они заданы».
Однако, необходимо понимать, что robots.txt – это набор

рекомендованных, в не обязательных правил для Google. Поэтому, если на
страницу, открытую для индексации и закрытую в robots.txt стоит внешняя
ссылка, то она, с некоторой долей вероятности будет обработана и
проиндексирована.
Если имеется второй вариант – в robots.txt запретов на индексацию

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

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

Так, для Яндекса, если робот обнаруживает конфликт между несколькими
мета-тегами, он учтет положительное значение:
<meta name= "robots" content="all"/>
<meta name="robots" content="noindex, follow"/>
<!–Робот выберет значение all, текст и ссылки будут проиндексированы.–>
C Google иная ситуация – он выполняет наиболее строгую директиву.

То есть, для приведенного выше примера робот проиндексирует только
ссылки, но не контент.

19
Типичные ошибки в robots.txt:
1. Имя файла содержит заглавные буквы
Файл должен называться robots.txt, а не Robots.txt или ROBOTS.TXT.
2. Использование файла robot.txt вместо robots.txt
Еще раз – файл должен называться robots.txt.
3. Перепутанные инструкции
Одна из самых распространённых ошибок в robots.txt – перепутанные

между собой инструкции. Например:
Disallow: Yandex
Правильно писать вот так:
User-agent: Yandex
Disallow: /
4. Указание нескольких каталогов в одной инструкции disallow
Многие владельцы сайтов пытаются поместить все запрещаемые к

индексации каталоги в одну инструкцию Disallow:
Disallow: /css/ /cgi-bin/ /images/
Такая запись нарушает стандарт, и невозможно угадать, как ее

обработают разные роботы. Правильно надо писать так:

20
Disallow: /css/
Disallow: /cgi-bin/
Disallow: /images/
5. Пустая строка в user-agent
Так неправильно:
User-agent:
Disallow:
Так правильно:
User-agent: *
Disallow:
6. Зеркала сайта и URL в директиве Host
Чтобы указать, какой сайт является главным, а какой – зеркалом

(дублем), для Google используются 301 редирект и внесение информации в
Google Search Console, а для Яндекса – директива host. Правда эта директива
была отменена весной 2018 года, но многие продолжают её использовать.
С точки зрения поисковых систем http://www.site.ru , http://site.ru ,

https://www.site.ru и https://site.ru – четыре разных сайта. Несмотря на то что
визуально для людей это одно и то же, поисковая система принимает
решение самостоятельно, какой сайт отображать в результатах выдачи, а
какой – нет. Казалось бы, в чем проблема? Их может быть несколько:

21
 поисковик Яндекс принял решение оставить у себя в индексе

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

принудительно сообщаем поисковикам, какой вариант сайта – с www или
без, с https или без него – для нас предпочтительнее, и избавляем себя от
возможных проблем в дальнейшем.
Итак, для протокола http следует писать без аббревиатуры протокола

передачи гипертекста, то есть без http:// и без закрывающего слеша /
Неправильно:
User-agent: Yandex
Disallow: /cgi-bin
Host: http://www.site.ru/
Правильно:
User-agent: Yandex
Disallow: /cgi-bin
Host: www.site.ru
Однако, если ваш сайт с https, то правильно писать вот так:
User-agent: Yandex
Disallow: /cgi-bin
Host:https:// www.site.ru

22
Директива host является корректной только для робота Яндекса,

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

зеркало можно установить в Яндекс вебмастере.
7. Использование в Disallow символов подстановки
User-agent: *
Disallow: file*.html
для указания все файлов file1.html, file2.html, file3.html и т.д. На

сегодняшний день – это вполне допустимо как для робота Яндекс так и
Google. Более того, Яндекс по умолчанию к концу каждого правила,
описанного в файле robots.txt, приписывается спецсимвол *. Пример:
User-agent: Yandex
Disallow: /cgi-bin* # блокирует доступ к страницам начинающимся с ‘/cgi-bin’
Disallow: /cgi-bin # то же самое
Чтобы отменить * на конце правила, можно использовать спецсимвол

$, например:
User-agent: Yandex
Disallow: /example$ # запрещает ‘/example’, но не запрещает ‘/example.html’
User-agent: Yandex
Disallow: /example # запрещает и ‘/example’ и ‘/example.html’

23
Спецсимвол $ не запрещает указанный * на конце, то есть:
User-agent: Yandex
Disallow: /example$ # запрещает только ‘/example’
Disallow: /example*$ # так же, как ‘Disallow: /example’
# запрещает и /example.html и /example
8. Редирект на страницу 404-й ошибки
Довольно часто, на сайтах без файла robots.txt при запросе этого файла
делается переадресация на другую страницу.
Иногда такая переадресация происходит без отдачи статуса 404 Not

Found. Пауку самому приходится разбираться, что он получил – robots.txt или
обычный html-файл. Эта ситуация вряд ли создаст какие-то проблемы, но
все-таки лучше всегда класть в корень сайта пустой файл robots.txt.
9. Заглавные буквы – это плохой стиль
USER-AGENT: GOOGLEBOT
DISALLOW:
Хотя по стандарту robots.txt и нечувствителен к регистру, часто к нему

чувствительны имена файлов и директорий. Кроме того, написание robots.txt
сплошь заглавными буквами считается плохим стилем.
10. Перечисление всех файлов
Еще одной ошибкой является перечисление каждого файла в

директории:

24
User-agent: *
Disallow: /AL/Alabama.html
Disallow: /AL/AR.html
Disallow: /Az/AZ.html
Disallow: /Az/bali.html
Disallow: /Az/bed-breakfast.html
Вместо этого можно просто закрыть от индексации директорию

целиком:
User-agent: *
Disallow: /AL/
Disallow: /Az/
11.Использование дополнительных директив в секции *
Некоторые роботы могут неправильно отреагировать на

использование дополнительных директив. Это значит, что не стоит
использовать дополнительные директивы в секции «*».
То есть рекомендуется создавать специальные секции для

нестандартных директив, таких как host.
User-agent: *
Disallow: /css/
Host: www.example.com

25
А вот так – правильно:
User-agent: *
Disallow: /css/
User-agent: Yandex
Disallow: /css/
12. Отсутствие инструкции Disallow
Даже если мы хотим просто использовать дополнительную директиву

и не хотим ничего запрещать, лучше всего указать пустой Disallow. По
стандарту инструкция Disallow является обязательной, и робот может
«неправильно вас понять».
User-agent: Yandex
Так правильно:
User-agent: Yandex
Disallow:
13. Отсутствие слешей при указании директории
Как в этом случае поступит робот?

26
User-agent: Yandex
Disallow: john
По стандарту, он не будет индексировать файл с именем «john» и

директорию с именем «john». Для указания только директории надо писать
так:
User-agent: Yandex
Disallow: /john/
14. Неправильный HTTP-заголовок
Сервер должен возвращать в HTTP-заголовке для robots.txt «Content-

Type: text/plain» а, например, не «Content-Type: text/html». Неправильный
заголовок может привести к тому, что некоторые роботы не обработают
файл.
15. Логические ошибки
Зачастую при разветвленной структуре сайта возникают логические

ошибки в определении того, что и как нужно блокировать от индексации.
Для Google: На уровне группы, в частности для директив allow и

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

27
Яндекс: Директивы Allow и Disallow из соответствующего User-agent

блока сортируются по длине префикса URL (от меньшего к большему) и
применяются последовательно. Если для данной страницы сайта подходит
несколько директив, то робот выбирает последнюю в порядке появления в
сортированном списке. Таким образом, порядок следования директив в
файле robots.txt не влияет на использование их роботом.
Исходный robots.txt:
User-agent: Yandex
Allow: /catalog
Disallow: /
Сортированный robots.txt:
User-agent: Yandex
Disallow: /
Allow: /catalog
# разрешает скачивать только страницы, начинающиеся с ‘/catalog’
Исходный robots.txt:
User-agent: Yandex
Allow: /
Allow: /catalog/auto
Disallow: /catalog
Сортированный robots.txt:
User-agent: Yandex
Allow: /
Disallow: /catalog
Allow: /catalog/auto

28
# запрещает скачивать страницы, начинающиеся с ‘/catalog’,
# но разрешает скачивать страницы, начинающиеся с ‘/catalog/auto’.
При конфликте между двумя директивами с префиксами одинаковой

длины в Яндексе приоритет отдается директиве Allow, в Google –
Disallow.
В любом случае протестируйте ваш robots.txt на конфликты в обоих

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

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

из robots.txt (что уже правильно – нельзя страницы пагинации там закрывать)
и прописывать такую конструкцию в заголовке страницы:
<meta name="robots" content="noindex, follow"/>
<meta name="yandex" content="index"/>
Таким образом, контент страницы пагинации не индексируется в

Google, но индексируется в Яндексе. При этом все ссылки страницы доступны
для индексации.

29
2.2.1. Проверка заблокированных документов в robots.txt
Если страница заблокирована для поисковых систем, она не появится в

поисковой выдаче. Страница может быть заблокирована для сканирования
либо директивой в файле robots.txt, либо с помощью метатега <noindex>.
Проверим страницы, блокированные robots.txt
Анализ производится в правой панели Screaming Frog  закладка

«Overview» (1), пункт «Response Codes» (2), подпункт «Blocked by Robots.txt»
(3).
В основной панели программы просматриваем все заблокированные в

robots.txt документы сайта

30
Решение: Проверьте, чтобы страницы с важным контентом не были случайно

заблокированы для сканирования поисковыми системами.
Чтобы протестировать robots.txt для различных ПС можно в настройках

конфигурации  User Agent
Указать, ботом какой ПС следует представляться программе.
Так можно протестировать различные секции robots.txt
Обратите внимание, что в этом случае нужно пересканировать сайт

заново.

31
2.3. Проверка Sitemap.xml
Если основное предназначение robots.txt – это запрет индексации, то

карта сайта sitemap.xml выполняет прямо противоположные задачи. Она
отвечает за ускорение индексации сайта и полноту индексации сайта.
Sitemap.xml указывает поисковой системе частоту, с которой возникает

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

файла. Ряд проверок (например поиск осиротевших страниц выполняется
программно, используя Screaming Frog и иные сервисы).
Файл Sitemap представляет собой XML-файл, в котором перечислены

URL-адреса веб-сайта в сочетании с метаданными, связанными с каждым
URL-адресом (дата его последнего изменения; частота изменений; его
приоритетность на уровне сайта), чтобы поисковые системы могли более
грамотно сканировать этот сайт.
Общее число sitemap.xml на сайте не должно превышать 1000, при

этом число записей (урлов) в каждом не должно превышать 50 000 штук.
Если необходимо перечислить более 50 000 URL-адресов, следует

создать несколько файлов Sitemap.
Карту сайта можно сжать gzip архиватором для уменьшения его

размера. Но объем каждого сайтмапа в развернутом (разархивированном)
виде не должен превышать 10 мегабайт.

32
Карта сайта не обязательно должна быть в виде xml файла. Протокол

допускает генерацию карты в виде синдикации (RSS или Atom) либо в виде
простого текстового файла с построчным перечислением URL. Но такие
«карты сайта» либо не включают в себя все URL сайта (в случае с
синдикацией), либо не несут дополнительную важную информацию (дата и
время модификации контента страниц), собственно ради которой и
используют в SEO карты сайта.
Предоставляя отметку времени последнего изменения <lastmod>, Вы

позволяете сканерам поисковой системы извлекать только часть файлов
Sitemap в индексе, то есть сканер может извлекать только те файлы
(страницы) сайта, которые были изменены после определенной даты. Этот
механизм частичного извлечения файлов из Sitemap.xml позволяет быстро
обнаруживать новые URL на сайтах больших размеров. Кроме того это
позволяет снизить нагрузку как на сервер, так и на краулер поисковой
системы. А последнее они (поисковые системы) крайне любят.
Инструкции sitemap.xml, robots.txt и метатегов robots при правильном

их использовании должны дополнять друг друга. Существуют три важнейших
правила взаимодействия этих инструкций:
1. sitemap.xml, robots.txt и метатеги robots не должны

противоречить друг другу;
2. все страницы, исключенные (заблокированные) в robots.txt и
метатегами robots, должны быть исключены также из
sitemap.xml;
3. все индексируемые страницы, разрешенные в robots.txt, должны
содержаться в sitemap.xml
Есть и исключения из этих трех правил. И, как всегда, они связаны со

страницами пагинации. Начиная со второй и далее страницы пагинации, мы

33
прописываем noindex,follow в метатегах robots, при этом в robots.txt

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

только канонические страницы, а начиная со 2 страницы пагинации – мета
тег cannonical на них установлен либо на первую страницу (версия
оптимизации для Яндекса), либо на страницу со всеми
товарами/статьями(версия для Google).
Оптимизаторы старой школы советуют добавлять в файл sitemap.xls

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

встречались следующие ошибки:
 Несоответствие sitemap.xml страницам сайта, устаревший

сайтмап. Эта проблема возникает, когда сайтмап генерируется
не динамически, а эпизодически, запуском какой то службы в
CMS, а то и сторонними сервисами. При этом возникает масса
мертвых страниц, отдающих 404 ошибку (это если страницу
физически удалили или перенесли в другое место, сменили
адрес URL). Кроме того, новые страницы индексируются
значительно медленнее, ибо не находятся в sitemap.xml.

34
 Следующая ошибка – неверная структура sitemap.xml. Эта

ошибка возникает, как правило, на «самописных» CMS или при
использовании неверных плагинов к популярной CMS. При этом
генерируется файл sitemap.xml с нарушением структуры,
описанной протоколом.
 Модификация этой ошибки – неверная работа с датой
изменения записи. С точки зрения протокола – это не ошибка,
так как поле lastmod не является обязательным. С точки зрения
SEO и поисковых систем, отсутствие правильного значения в этом
поле (совпадающее с непосредственным изменением контента)
– полностью нивелирует значимость всего файла sitemap.xml. Как
было сказано выше, ПС будут переиндексировать те страницы,
поле lastmod которых изменилось. Что произойдет, если это поле
меняется одновременно у всех записей (страниц) сайта. То есть
дата модификации одинакова у всех файлов сайта. Скорее всего,
ПС не будут обращать внимание на sitemap и сайт будет
переиндексироваться обычным способом, при этом глубоко
расположенные страницы либо не переиндексируются вовсе,
либо будут переиндексироваться очень долго. Итак, Необходимо
или вовсе не использовать поле lastmod (что плохо), либо ставить
дату последнего значимого изменения страницы, например,
когда поменялась цена или товар закончился или изменилось
описание.
 Следующая группа встречаемых ошибок – логические ошибки,
вызваны нарушением трех правил о сочетании robots.txt и
sitemap.xml. В этом случае можно наблюдать постоянное
попадание страницы в индекс и немедленный вылет оттуда.
Однако, это не будет наблюдаться при наличии метатега noindex

35
и записи в Sitemap.xml. В этом случае краулер (робот, паук ПС),

зашедший на страницу индексировать её не будет.
 Ну и последняя ошибка, часто встречающаяся на сайтах –
наличие «осиротевших страниц». Это такие страницы, на
которые стоит ссылка из sitemap, но нет ни одной прямой ссылки
с любой из страниц сайта. Часто это связано с тем, что страницы
были удалены «логически» (например в WordPress помещены в
корзину), а не физически. Это так же наблюдается на сайтах, где
доступ к карточкам товаров сделано на скриптах и фильтрах
способом, который не позволяет проиндексировать результаты
работ этих скриптов. Возможны и иные причины возникновения
таких страниц-сирот. Все это снижает доверие поисковых систем
к сайту и является негативным сигналом ранжирования.

36
2.3.1. Файл sitemap.xml не указан в файле robots.txt
Если на вашем сайте есть и файл sitemap.xml, и файл robots.txt,

рекомендуется разместить ссылку на sitemap.xml в robots.txt, что позволит
поисковым системам точнее определить, какие страницы им следует
сканировать.
Откройте ваш файл robots.txt и проверьте наличие сайтмапа в нем.
Решение: Укажите расположение файла sitemap.xml в файле robots.txt.

37
2.3.2. Наличие осиротевших (изолированных) страниц
Изолированная страница (осиротевшая страница)— это страница, на

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

выгрузка «Orphan Pages» (2) в меню «Reports» программы Screaming Frog.
Решение: Проверьте все изолированные страницы в файлах sitemap.xml и

выполните одно из следующих действий:
 Если страница больше не нужна, удалите ее.

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

38
2.4. Использование протокола HTTP/2
HTTP/2 – новая версия протокола HTTP, стандартизированная в начале

2015 года. Использование HTTP/1.1 из-за некоторых особенностей вносит
негативный эффект на производительность веб-приложений. HTTP/2 тесно
связан с SSL. Несмотря на то, что спецификация не требует обязательного
использования SSL, все веб-браузеры выпущенные на текущий момент будут
работать с HTTP/2 только если веб-сайт использует SSL.
Итак, если ваш сайт работает на https, то использование http/2 крайне

желательно по многим причинам, например – параллельной загрузке
данных, что несколько увеличивает скорость работы сайта.
Проверить можно во многих онлайн-чекерах, например тут:
https://http2.pro
Решение: узнайте у вашего хостера, как вам перейти на протокол http/2.

39
2.5. Отсутствие переадресации и канонических ссылок с HTTP на HTTPS-

страницу
Если вы используете обе HTTP и HTTPS версии главной страницы,

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

http версию главной. Если нет, проверьте, прописан ли в исходном коде http
версии страницы атрибут rel="canonical" на версию с https.
Решение: Выполните одно из действий:
 Настройте переадресацию 301 со страницы HTTP на HTTPS

 Установите на HTTP-странице атрибут rel="canonical", задав
страницу HTTPS как предпочтительную
Обязательно проверьте во всех используемых вебмастерах, какая

версия страницы считается главной.

40
И для Google

41
3. Структура сайта, хостовые факторы и URL
3.1. Анализ уровня вложенности
Анализ производится в правой панели Screaming Frog  закладка «Site

Structure».
Обычно считается допустимым 3 уровня вложения (3 клика от главной).

Список страниц, выходящих за пределы 3-х кликов можно получить во
вкладке Internal (1), установив фильтр HTML (2) и промотав значения вправо
до столбца Crawl Depth, нажав на который можно отсортировать данные.

42
Методы борьбы со слишком большим уровнем вложенности:
 Вынесение в витрину на главную большего числа

рубрик/категорий.
 Внедрение кроссел/апселл товаров в карточках или, что то же
самое – похожих статей для каждой статьи.
 Внедрением большего числа рубрик и фильтров.
 Внутренняя перелинковка.

43
3.2. Входящие внутренние ссылки
Чем больше уникальных входящих ссылок, тем более важной будет

считаться страница в глазах ПС. Определяем, на какие страницы при текущей
оптимизации делаются основные акценты.
Анализ производится в основной панели Screaming Frog  закладка

«Internal» (1), фильтр «HTML» (2), столбец «Unique Inlinks» (3).
При анализе анкоров устанавливаем в нижней панели вкладку «Inlinks»
Проверяем правильность распределения весов на важнейшие

страницы и соответствие внутренних анкоров семантическому ядру.

44
3.3. Анализ 3XX редиректов
Ошибки при использовании редиректов приводят к снижению

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

«Internal» (1), фильтр «HTML» (2), столбец «Status Code» (3).
Данные сортируются по столбцу. Далее проматываются вверх/вниз до

поиска страниц с 3XX редиректами. В нижней панели на вкладке «Url Info» (1)
наблюдаем с какого URL (2) на какой именно (3) происходит редирект.

45
В идеале, на сайте не должно быть страниц с внутренними ссылками

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

порождаются эти редиректы: Выделяем анализируемый редирект,
переключаем нижнюю панель на Inlinks (1), смотрим с какой страницы (2)
идет ссылка на старый адрес (3)и с каким анкором (4).
Все ссылки в пределах сайта со старыми адресами необходимо

сменить на новые URL.
Типичными ошибками 3XX редиректов являются:
 Использование многошаговой цепочки редиректов, редирект не

на 200 страницу.
 Наличие ссылок на старые адреса в пределах сайта –
т.е.внедрение внутренних редиректов без смены ссылок на
новые адреса.
 Редирект между страницами с разным контентом, кроме
использования приемов обрезки и объединения в пределах
сайта.
 Использование редиректов для robots.txt (но не sitemap.xml)
 Использование редиректов на внешние сайты по внутренним
ссылкам, которые на закрыты от индексирования (неверная
маскировка аффилейт ссылок).

46
После удаления ссылок на старые адреса HTML страниц необходимо

проверить остальные редиректы.

«Response Codes» (1), фильтр «Redirection (3xx)» (2).
Проверьте необходимость наличия всех выявленных редиректов. Здесь

правило таково – чем меньше, тем лучше.

47
3.3.1. Цепочки и петли переадресации
Переадресация с одного URL на другой бывает необходима. Однако

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

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

возможно, ваш сайт по-разному реагирует на запросы поисковых систем и
браузеров.
Решение: Лучший способ избежать проблем – использовать не более трех

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

48
3.3.2. Временная переадресация
Временная переадресация (то есть переадресация с кодами состояния

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

переадресации с кодами состояния 302 и 307. Не забудьте удалить
переадресацию, когда в ней больше не будет необходимости. Однако если
какая-либо из страниц перемещена постоянно, замените переадресацию с
кодами состояния 302/307 на переадресацию с кодами состояния 301/308.

49
3.4. Анализ 4XX страниц
Все не существующие страницы сайта должны отдавать ошибку 404.

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

(редирект) с них на главную или иную страницу сайта, отдающую код 200.
При анализе 404 ошибок на сайте возможны типичные проблемы:
 Отсутствие 404 ошибки для несуществующей страницы

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

удалением этой страницы, желательно отдавать код 410 при доступе к
удаленной странице.
Логика работы с 404 ошибками такова:
 Если 404 ошибка вызвана внутренними ссылками на

несуществующие страницы – необходимо исправить ссылку на
корректный URL или удалить такую ссылку.
 Если 404 ошибка вызвана внешними ссылками – необходимо
поставить 301 редирект на новый материал.

«Response Codes» (1), фильтр «Client Error (4xx) (2).

50
Далее мы выбираем в нижней панели закладку «Inlinks» и проверяем

где и какими ссылками порождаются 404 ошибки.
Далее, в Google Search Console смотрим ошибки сканирования (те же

404 ошибки) и исправляем найденное.

51
3.5. Страницы с кодом состояния 5XX
Группа кодов статусов HTTP 5хх связана с ошибками на стороне

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

«Overview» (1), пункт «Response Codes» (2), подпункт «Server Error (5xx)» (3).
Решение: Выясните (по номеру кода) причины возникновения этих ошибок и

попытайтесь их устранить.

52
3.6. Анализ пагинации на сайте
Проверьте настройку пагинации для рубрик товаров или каталога

статей. Здесь возникает ошибка у большинства Интернет – магазинов и
информационных сайтов со значительным объемом страниц.
1. Все страницы пагинации должны быть «сшиты» в единый кластер.
Например, есть страница - каталог
SITE.RU/KOTEL
На ней организована пагинация обычным линком <a href > на 2

страницу:
SITE.RU/KOTEL?PAGE=2
Разумно было бы предполагать, что ссылка со второй страницы ведет

назад в каталог, на страницу SITE.RU/KOTEL, однако некоторые товарищи
ставят ссылку на такую страницу SITE.RU/KOTEL?PAGE=1
При этом страницы SITE.RU/KOTEL и SITE.RU/KOTEL?PAGE=1 – прямые

дубли.
Как минимум, в этом случае нужно сделать 301 редирект (что не особо
хорошо) со страницы SITE.RU/KOTEL?PAGE=1 на SITE.RU/KOTEL.
В идеале поправить линк на правильную страницу.
Если вы добавляете пагинацию в sitemap.xml, проконтролируйте нет ли

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

Next в заголовках страниц пагинации.

53
Проверьте куда ведут ссылки со второй страницы, на каталог или на

первую страницу.
Теперь откройте последнюю страницу пагинации и проконтролируйте,

чтобы мета - тег Next отсутствовал.
Google настоятельно рекомендует указывать мета – тег Canonical на

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

каталога, т.е. на категорию. Учитывая, что Canonical – по сути скрытый 301
редирект, пользы от такого совета немного.
Делать канонической саму же страницу пагинации – тоже не

оптимальный выбор.
Учитывая крайне низкое качество страниц пагинации и их

практическую идентичность, не забывайте проверить, что в Title и в
Description и в H1 добавлен текущий номер страницы пагинации.
SEO оптимизированный текст, написанный для страницы категории не

должен попадать на страницы пагинации.
Итак, как должны быть организованы страницы пагинации.
Для начала проверьте, что страница номер 1 (идентичная главной

странице каталога) отсутствует:
 https://site.ru/katalog-statej - главная страница каталога

 https://site.ru/katalog-statej?page=1 - первая страница каталога
(полный дубль главной страницы).

54
Для этого, находясь на 2 странице каталога посмотрите в коде куда

ведет ссылка непосредственно пагинации
И как настроен мета-тег Prev.
Таким образом, сначала идет главная страница каталога, потом сразу

вторая и т.д.
Для стартовой страницы каталога:
https://site.ru/katalog-statej
необходимо прописать в разделе head страницы следующее:
<link rel="next" href="https://site.ru/katalog-statej?page=2">
При этом на странице в мета-тегах должно быть указано :
<meta name="robots" content="index, follow">
Теперь переходим ко второй странице каталога:
https://site.ru/katalog-statej?page=2
Здесь в разделе head должно быть прописано:
<link rel="prev" href="https://site.ru/katalog-statej">
<link rel="next" href="https://site.ru/katalog-statej?page=3">
А так-же:
<meta name="robots" content="noindex, follow">
<link rel="canonical" href="https:// site.ru /katalog-statej"/>

55
Это вариант для Яндекса. При оптимизации под Google canonical

необходимо указывать на страницу, которая содержит все статьи
полностью(у вас такой нет). И для Google вовсе не обязательно указывать
noindex.
Последняя страница пагинации:
https://site.ru/katalog-statej?page=300
должна иметь в заголовке:
<meta name="robots" content="noindex, follow">
<link rel="canonical" href="site.ru/katalog-statej"/>
<link rel="prev" href="https://site.ru/katalog-statej?page=299">
Т.е. метатег Next мы не используем.
Проверьте еще:
1. SEO текст добавлен только на главной странице каталога и не

дублируется на страницах с пагинацией
2. Страницы пагинации отсутствуют в sitemap, кроме главной (если вы
решите прописать мета-тег noindex)

56
3.7. Слишком длинный URL
По алгоритмам Google URL-адреса длиной свыше 100 символов не

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

«Overview» (1), пункт «URI» (2), подпункт «Over … Charachters» (3).
(Максимально приемлемая длина устанавливается в конфигурации, в
настройках Spider)
Решение: Ничего не делать. Однако если вы будете изменять когда-либо

структуру сайта, то измените URL-адреса таким образом, чтобы их длина
составляла менее 100 символов.

57
3.8. Символ подчеркивания в URL
Если говорить о структуре URL, не рекомендуется использовать

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

«Overview» (1), пункт «URI» (2), подпункт «Underscores» (3).
Решение: Ничего не делать, особенно если страница трафиковая. Однако

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

58
3.9. Слишком много параметров в URL
С точки зрения оптимизации для поисковых систем не рекомендуется

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

«Overview» (1), пункт «URI» (2), подпункт «Parameters» (3).
Решение: Ничего не делать, особенно если страница трафиковая. Однако

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

59
4. Анализ HTML кода, тегов и метатегов
4.1. Страницы с избытком внутренних ссылок

«Internal» (1), фильтр «HTML» (2), столбцы «Outlinks» (3) и «Unique Outlinks»
(4).
Данные сортируются по столбцу Outlinks (исходящие ссылки).

Отбираются страницы с большим числом внутренних исходящих ссылок и
проводится их проверка. При этом проводится сопоставление со столбцом
«Уникальные ссылки» (4). Если расхождения очень велики, то вы неверно
настроили внутреннюю перелинковку и «ссылочный сок» теряется, так как
учитывается только единственная ссылка со страницы (подробнее см раздел
10 «Внутренняя перелинковка» учебника «SEO Монстр 2018»).
Так же проверяем отсутствие страниц без единой исходящей ссылки –

так называемые «зависшие узлы».

60
4.2. Страницы с избытком внешних ссылок

«Internal» (1), фильтр «HTML» (2), столбцы «External Outlinks» (3) и «Unique
External Outlinks» (4).
Данные сортируются по столбцу External Outlinks (внешние исходящие

ссылки). Далее проверяем внешние ссылки на их необходимость и
уместность. Часто наличие большого числа внешних ссылок свидетельствует
о взломе сайта.
Чем меньше внешних ссылок стоит со страницы – тем лучше (но не до

маразма).
Обратите внимание на соответствие количества внешних ссылок и

уникальных внешних ссылок. Если будут расхождения, то дубли внешних
ссылок лучше всего удалить (в большинстве случаев).

61
4.3. Нерабочие внешние ссылки
Если по нерабочей внешней ссылке пользователь перейдет с одного

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

«External» (1), фильтр «HTML» (2), столбeц «Status Code» (3).
Данные сортируются по столбцу Status Code.
Анализируются все строки с кодом, отличающимся от 200. Особое

внимание обращаем на 4XX и 5XX ошибки.

62
Выбрав строку с битой ссылкой (1), переходим к нижней панели и

определяем страницу, где расположена битая ссылка (2).
Решение: Удаляем битую ссылку или меняем адрес на корректный.

63
4.4. Страницы без тега Title
Заголовок (Title) – это один из самых важных факторов оптимизации

страницы. Именно его первым видит посетитель поисковой системы в
органической выдаче. Именно его он первым оценивает и принимает
решение перейти или нет на сайт. Именно поэтому недопустимо отсутствие
заголовка у любой HTML страницы.
Тег <title> выступает ключевым объектом оптимизации страницы для

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

«Overview» (1), пункт «Page Titles» (2), подпункт «Missing» (3).
Решение: Добавьте заголовок Title на те страницы, у которых он не

обнаружен.

64
Если вы не хотите упустить возможность занять высокую позицию в

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

обладать следующими свойствами:
1. Он должен быть привлекательным и выделяться чем либо в

органической выдаче (например, УТП – уникальным торговым
предложением).
2. Он должен быть правдивым, иначе пользователь, не увидев
подтверждения заголовку на сайте, вернется в выдачу, тем
самым повысив показатель отказа.
Есть статистика, что при увеличении CTR в выдаче на 3-4%, позиция в

органике улучшается на 1. Именно привлекательность заголовка (и сниппета
в целом) обеспечивает высокий CTR.

65
4.5. Страницы c дублирующимися тегами Title
В пределах сайта все теги Title должны быть уникальны. Допуская

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

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

«Overview» (1), пункт «Page Titles» (2), подпункт «Duplicate» (3).

66
Решение: Устраните дубли заголовков страниц.
Укажите в теге <title> каждой из страниц уникальное и краткое

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

Добавляйте в этом случае для каждой из страниц пагинации её номер в
конце заголовка.

67
4.6. Страницы c совпадающими тегами Title и H1
Дублировать содержимое тега <title> в заголовке первого уровня не

рекомендуется. Если текст в тегах <title> и <h1> совпадает, то страница может
восприниматься поисковыми системами как чрезмерно оптимизированная.
Кроме того, если теги <h1> и <title> дублируют друг друга, вы упускаете
возможность использовать другие подходящие ключевые слова для вашей
страницы.

«Overview» (1), пункт «Page Titles» (2), подпункт «Same as H1» (3).
Решение: Устраните дубли заголовка и H1.
Как правило, H1 – более короткое описание страницы, включающее в

себя ключевое слово. Заголовок - расширенное описание страницы,
включающее в себя несколько ключевых слов и/или LSI синонимы главного
ключевого слова и УТП.

68
4.7. Страницы c несколькими тегами Title
Тег Title должен быть уникальным в пределах страницы.

«Overview» (1), пункт «Page Titles» (2), подпункт «Multiple» (3).
Решение: Устраните дубли тега title

69
4.8. Излишне длинные/короткие теги Title
Большинство поисковых систем укорачивают названия страниц (как

правило соответствует тегу Title), содержащие более 65-75 символов в
органической выдаче. Обрывающееся название страницы выглядит
непривлекательно для пользователей, которые вряд захотят перейти по
такой ссылке, что снижает CTR в огранике.
Однако, у разных ПС разные размеры выводимого названия. Более

того, у одной ПС эти размеры могут постоянно меняться.
Текущие размеры выводимого Title в органике ПС можно посмотреть

тут: https://www.rankranger.com/google-serp-features
Как мы видим, для России на июль 2018 длина Title выводимая в

органике Google составляет около 52-53 символов. Все остальное будет
обрезано.

70
Чтобы настроить Screaming Frog на эти показатели, пройдите в меню в

конфигурацию Spider
Далее в закладке Preferences установите минимальные (1) и

максимальные (2) значения длины Title в символах.
После этого пересканируйте сайт (если это нужно).

«Overview» (1), в следуюших пунктах:

71
Решение: Вам, возможно, надо переписать излишне длинные или излишне

короткие Title (заголовки) ваших страниц.

72
4.9. Отсутствует описание страницы (метатег Description)
Description (описание) - метатег, который находится в HTML-коде

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

страницы, а самое главное, он влияет на генерацию сниппета, в Яндексе –
реже, в Google – чаще, что сказывается на CTR выдачи и на поведенческих
факторах. Таким образом, можно считать, что Description косвенным
образом влияет на позиции в ТОПах.
Продуманное описание помогает пользователям понять, о чем ваша

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

сайта.

«Overview» (1), пункт «Meta Description» (2), подпункт «Missing» (3).

73
Если вы заинтересованы в повышении соотношения числа переходов и

числа показов (CTR), проверьте наличие метаописания с подходящими
ключевыми словами на всех ваших страницах.
Решение: Прописать отсутствующие описания страниц.

74
4.10. Дублирование метатега Description
Тег <meta description> содержит краткое описание страницы. Он

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

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

«Overview» (1), пункт «Meta Description» (2), подпункт «Duplicate» (3).
Решение: Уникализировать дубли описания страниц, используя разные

ключевые слова в соответствии с разработанным семантическим ядром.

75
4.11. Использование нескольких метатегов Description на странице
Тег <meta description> должен быть описан на странице только 1 раз.

Использование нескольких метаописаний в пределах страницы – ошибочно.

«Overview» (1), пункт «Meta Description» (2), подпункт «Multiple» (3).
Решение: Удалить повторные метаописания страницы.

76
4.12. Использование излишне коротких/длинных метаописаний
Анализ этой ошибки идентичен анализу размера тега Title. Настройка

Screaming Frog выполняется аналогично.
Эталонные значения можно так же посмотреть в сервисе:
https://www.rankranger.com/google-serp-features
Так для России, на июль 2018 года выводимая длина описания в

органике Google составляет 134 символа.
Решение: Как правило, метаописания, если они имеют хороший CTR лучше
не трогать, даже если они немного длинней указанных значений.

77
4.13. Страницы без тега H1
Хотя тег <h1> менее важен, чем <title>, содержащийся в нем заголовок,
тем не менее, помогает определить тему вашей страницы поисковым
системам и пользователям. Если тег <h1> не заполнен или отсутствует, то
поисковые системы могут понизить позицию страницы в результатах поиска.
Кроме того, отсутствие тега <h1> нарушает иерархию заголовков на странице,
что ухудшает ее рейтинг для поисковых систем.

«Overview» (1), пункт «H1» (2), подпункт «Missing» (3).
Просмотрите в основной панели программы страницы без

использования тега H1.
Решение: Укажите краткий подходящий заголовок в теге <h1> для

каждой из страниц.

78
4.14. Дублирующиеся H1 в пределах сайта
Все теги H1 на всех страницах сайта должны быть уникальными.

«Overview» (1), пункт «H1» (2), подпункт «Duplicate» (3).
Просмотрите в основной панели программы страницы с дублями H1.
Решение: Перепишите H1 для всех страниц с дублями. Возможно, вам

придется исправить шаблон сайта. Для страниц пагинации можно добавить в
H1 текущий номер страницы этой категории.

79
4.15. Несколько H1 в пределах страницы
Несмотря на то, что в структуре HTML5 разрешено использовать

несколько тегов <h1>, я не рекомендую использовать более одного тега <h1>
на странице. Добавление нескольких тегов <h1> может ввести в заблуждение
пользователей.

«Overview» (1), пункт «H1» (2), подпункт «Multiple» (3).
Просмотрите в основной панели программы страницы с

неоднократным использованием H1.
Решение: Используйте теги <h2>-<h6> вместо повторного применения тега

<h1>.

80
4.16. Проверка метатега viewport
Метатег <viewport> представляет собой HTML-тег, который позволяет

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

метатег viewport.
Решение: Проверьте готовность шаблона вашего сайта к просмотру на

мобильных устройствах (см. Приложение 2). Укажите метатег viewport для
каждой страницы.

81
4.17. Проверка lang и hreflang
Проверьте, используете ли вы на странице атрибуты lang и hreflang.

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

путем добавления атрибута lang). В противном случае текст на веб-сайте
может не распознаваться поисковыми системами. Он также может не
попасть в результаты поиска или отображаться в них некорректно.

атрибут lang.
Решение: Выполните следующее:
 Добавьте атрибут lang в тег <html>, например: "<html lang="ru">".

 Если необходимо, то добавьте атрибут hreflang в тег <head> на
своей странице, например: <link rel="alternate"
href="http://example.com/" hreflang="ru"/>.

82
4.18. Проверка кодировки
Кодировка указывает веб-браузерам, какой набор символов следует

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

аттрибут charset.
Если атрибут не найден, посмотрите любым HTTP Viewer его HTTP

заголовки, например, здесь:
https://www.httpdebugger.com/Tools/ViewHttpHeaders.aspx
Решение: Укажите кодировку либо в параметре charset в заголовке HTTP

Content-Type (Content-Type: text/html; charset=utf-8), либо с помощью
атрибута meta charset в HTML-коде страницы (<meta charset="utf-8"/>).

83
4.19. Проверка типа документа
Тип документа указывает веб-браузерам, какая версия HTML или

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

элемент doctype.
Решение: Укажите тип документа для каждой страницы путем добавления

элемента (например, <!Doctype HTML5>) в самой верхней строке исходного
кода каждой страницы, непосредственно перед тегом <html>.

84
4.20. Нерабочая каноническая ссылка
Добавляя элемент rel="canonical" на страницу, вы указываете

поисковым системам, какая версия страницы должна отображаться в
результатах поиска. При использовании тегов "canonical' важно убедиться,
что URL, который вы указываете в элементе rel="canonical", ведет на
существующую страницу. Канонические ссылки на несуществующие
страницы усложняют процесс сканирования сайта и индексирования
контента, что снижает эффективность сканирования и означает
нерациональное расходование бюджета сканирования.

«Overview» (1), пункт «Directives» (2), подпункт «Canonicalised» (3).
Далее, в основном окне программы нужно просмотреть список

страниц, обратив внимание на столбец Canonical Link Element 1.

85
При этом в нижнем окне, в закладке URL Info (2) мы должны видеть,
что каноническая страница имеет код 200 (3).
Решение: Проверьте все нерабочие канонические ссылки. Если

канонический URL соответствует несуществующей странице, удалите его или
замените на URL другой страницы.

86
5.Анализ контента
5.1. Поиск низкоуникальных страниц в пределах сайта
Дублированный контент - это одинаковый контент, найденный на двух

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

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

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

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

контента на сайте можно воспользоваться следующим инструментом:
http://www.siteliner.com/
Помимо поиска неуникального контента вы получите еще немного

интересных технических данных.

87
Необходимо различать дублированный контент (Duplicate Content)и

общий контент (Common Content). Если первый – это прямые дубли текста на
двух или нескольких страницах, то общий контент – это контент из шапки,
сайдбара, футера. Немного технических данных на сегодняшний день. По
статистике средний объем по всему Интернету составляет: Для
дублированного контента – 38 %, для общего контента – 15%
Как это возникает? Да очень просто. На каждой карточке товара в

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

88
Здесь можно выделить наиболее неуникальные страницы
И необходимо разобраться с неуникальностью, чтобы повысить

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

контента:
 Добавьте уникальный контент на страницу.

 Удалите повторяющийся контент.
 Добавьте ссылку rel="canonical" на одну из дублирующих
страниц, чтобы указать поисковым системам, какую страницу
следует отображать в результатах поиска.

89
5.2. Страницы с малым содержанием контента (Thin Content)
Объем текста, размещенного на странице, является одним из

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

пользователю как можно больше информации, поэтому страницы с
объемным контентом, как правило, опережают в результатах поиска те, на
которых мало текста.

«Internal» (1), фильтр «HTML» (2), столбец «Word Count» (3).
Данные сортируются по столбцу. Отбираются страницы с малым

содержанием слов и анализируются вручную.
Решение: Доработайте контент страницы, добавив на нее более 200

значимых слов.

90
5.3. Страницы с низким соотношением контента к коду

«Internal» (1), фильтр «HTML» (2), столбец «Text Ratio» (3).
Данные сортируются по столбцу. Отбираются страницы с низким

уровнем Text Ratio (процентное отношение объема контента к коду html
страницы).
Показатель прямо зависит от числа слов контента. Однако, он может

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

страниц проверяют код, выносят все инлайн вставки JS скриптов, CSS в
отдельные файлы.

91
5.4. Flash элементы
Несмотря на то, что страницы с элементами Flash могут выглядеть

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

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

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

устройствах.

«Overview» (1), раздел «SEO Elements» (2), пункт «Internal»(3),подпункт
«Flash» (4).

92
Так мы находим Flash файлы, размещенные на хостинге.
Далее анализ производится в правой панели Screaming Frog 

закладка «Overview» (1), раздел «SEO Elements» (2), пункт
«External»,подпункт «Flash».
Так мы находим внешние Flash файлы.
Решение: По возможности старайтесь избегать использования элементов

Flash на странице.

93
5.5. Смешанный контент
Присутствие элементов на HTTPS-страницах , не защищенных

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

URL содержать https

«Overview» (1), раздел «Protocol» (2), пункт «HTTP»(3).
Решение: Добавляйте на страницы HTTPS только контент, защищенный

протоколом HTTPS.

94
6. Анализ проблемных страниц
6.1. Страницы с высоким процентом отказов
Необходимо изучить страницы с высоким процентом отказов. Причины

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

«Internal» (1), фильтр «HTML» (2), столбeц «GA Bounce Rate» (3). Обязательно
должен быть подключен API Google Analytics Solutions.
Данные сортируются по столбцу GA Bounce Rate (проценты отказа). Чем

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

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

95
6.2. Страницы, отсутствующие в органической выдаче
Необходимо изучить страницы, которые не попадают в органическую

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

«Internal» (1), фильтр «HTML» (2), столбeц «Impressions» (3).
Обязательно должен быть подключен API Google Search Console.
Данные сортируются по столбцу Impressions (показы). Ищутся страницы

с отсутствующими или очень низкими показателями
Решение: необходимо получить список страниц не показывающиеся в

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

96
6.3. Страницы с низким CTR
Чем выше CTR у страницы, тем лучше её позиции по запросам в

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

«Internal» (1), фильтр «HTML» (2), столбeц «CTR» (3).
Обязательно должен быть подключен API Google Search Console.
Данные сортируются по столбцу CTR. Ищутся страницы с низкими

показателями CTR (меньше - хуже).
Решение: проверьте сниппет данной страницы, корректность и

привлекательность Title и Description, переработайте их и добавьте УТП для
повышения привлекательности сниппета.

97
6.4. Страницы с малым временем просмотра
Если посетитель быстро покидает страницу, значит он не нашел

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

«Internal» (1), фильтр «HTML» (2), столбeц «GA Avg Time on Page» (3).
Обязательно должен быть подключен API Google Analytics.
Данные сортируются по столбцу GA Avg Time on Page. Ищутся страницы

с низкими показателями времени просмотра (меньше - хуже).
Решение: проверьте наличие контента на этих страницах, отсутствие

технических ошибок на них, соответствие сниппета в органике наличному
контенту (не вводите ли вы посетителя в заблуждение).

98
6.5. Страницы с большим временем загрузки
Скорость загрузки страницы является одним из наиболее важных

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

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

«Internal» (1), фильтр «HTML» (2), столбeц «Response Times» (3).
Данные сортируются по столбцу Response Times. Ищутся страницы с

наибольшим временем загрузки (больше - хуже).

99
К основным факторам, которые оказывают отрицательное влияние на

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

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

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

https://goo.gl/6VECZ8
2. Уменьшить размер графики, вычистить из них мета данные и
пережать.
https://kraken.io/web-interface
http://www.punypng.com/
https://tinypng.com/
3. Сделать для каждого изображения набор изображений под разные
разрешения и размеры экрана. Некоторые CMS могут делать это на
лету, при загрузке изображений в него.
4. Включить кэширование в браузере.
https://developers.google.com/web/fundamentals/performance/optimi
zing-content-efficiency/http-caching?hl=ru

100
5. Сократить число css или объединить все css в единый файл и сжать
его. CSS должен подключаться в теле HTML-документа как можно
выше.
http://www.cssdrive.com/index.php/main/csscompressor/
6. Сократить число Java скриптов, сжать их, подгружать асинхронно,
загрузку скриптов перенести в конец документа.
https://developers.google.com/web/fundamentals/performance/critical
-rendering-path/adding-interactivity-with-javascript?hl=ru
Сейчас вам просто необходимо отобрать наиболее медленные

страницы сайта и проверить их, опираясь на данные следующей главы 8.

101
7. Проверка изображений
7.1. Поиск неработающих изображений
Внутреннее изображение не отображается на сайте по причине того,

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

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

«Internal» (1), фильтр «Images» (2), столбeц «Status Code» (3).
Данные сортируются по столбцу Status Code. Ищутся изображения с

кодом, отличающимся от 200.

102
Далее, переходим к нижнему окну, выделив битое изображение (как

правило – это 404 код).
Переходим в закладку «Inlinks» (1) и смотрим на каких страницах

используется это изображение (2) в столбце From.
Решение: Замените все не открывающиеся изображения на корректные или

удалите их со страниц.

103
7.2. Изображения без alt тега
Атрибут alt в теге <img> необходим для того, чтобы поисковые системы
могли определить тематику изображения. Пренебрегая атрибутом alt, можно
упустить возможность занять более высокую позицию в поисковой выдаче,
поскольку именно наличие атрибутов alt определяет рейтинг в результатах
поиска изображений.
Отсутствие атрибутов alt также отрицательно сказывается на опыте

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

«Overview» (1), пункт «Images» (2), подпункт «Missing Alt Text» (3).
Выбираем «Missing Alt Text» и переходим к основной панели Screaming

Frog, где получим список всех изображений без alt текста.

104
Здесь выделяем исследуемое изображение и переходим к нижней

панели программы.
Где используя закладку Inlinks (1) мы находим URL страниц (2) с этим
изображением без alt текста.
Решение: Укажите соответствующий атрибут alt внутри тега <img> каждого

изображения на сайте, например <img src="mylogo.png" alt="Это логотип
моей компании">.

105
7.3. Поиск неоптимизированных изображений
Изображения – это именно те ресурсы, которые занимают много места

на странице и весят больше всего. Благодаря их оптимизации мы можем
значительно уменьшить количество скачиваемых данных и улучшить работу
сайта.
Согласно HTTP-архиву, 60% данных представляют собой изображения,

состоящие из JPEG, PNG и GIF. По состоянию на начало 2018 года, на
изображения приходилось 1.7 Mb содержимого, загруженного на страницу
сайта среднего размера в 3.0 Mb.
Чем больше сжато изображение, тем меньше пропускной способности

канала занимает скачивание и тем быстрее браузер сможет показать
страницу пользователю.

«Overview» (1), пункт «Images» (2), подпункт «Over … kb» (3).
Здесь мы отбираем изображения, больше определенного предела (в

примере это 100kb). Вы можете самостоятельно установить ограничения на

106
минимальный размер изображения в конфигурациях программы (раздел

spider).
Решение: необходимо выполнить оптимизацию изображений в соответствии

с Приложением 1.

107
8. Кейс: Скорость загрузки страниц сайта
Страницы с медленной загрузкой разочаровывают пользователей,

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

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

времени, а тем самым и чаще и больше конвертируются на сайтах, которые
загружаются быстрее. Есть исследование от WPO (https://wpostats.com/ ), что
увеличение конверсии на 7% обусловлено повышением скорости всего на
0,85 секунды.
Медленная загрузка вредна для поисковой оптимизации, так как

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

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

расширением LightHouse для Chrome

108
https://chrome.google.com/webstore/detail/lighthouse/blipmdconlkpinefe
hnmjammfjpmpbjk
В последних версиях Хрома он уже встроен: «Дополнительные

инструменты»  «Инструменты разработчика»  Вкладка «Аудит».
Инструмент позволяет найти «узкие места» на вашем сайте и провести

оптимизацию страниц.
Следующим инструментом является классический PageSpeed Insights.
https://developers.google.com/speed/pagespeed/insights/
PageSpeed Insights анализирует содержание веб-страницы и предлагает

решения, которые позволят ускорить ее загрузку.
Далее обратите внимание на Web Page Test:
https://www.webpagetest.org/

109
Он проводит серию тестов по URL-адресу и генерирует несколько

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

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

dareboost.com, который позволяет не только замерять скорость работы
сайта, но и выполнить несколько десятков полезных тестов страниц.
В демо версии доступно 5 исследований страниц бесплатно.
Итак, регистрируемся здесь: https://www.dareboost.com/en/dashboard

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

110
8.1. Оценка производительности страниц сайта
Анализировать будем на примере главной страницы drmax.su:
https://www.dareboost.com/en/report/d_5b503639e967905afa24e883
Во время загрузки главной страницы drmax.su было сделано 122

запроса к серверу (это много) и общий объем загруженных данных составил
7,59 Mb (это крайне много).
Нажав на кнопку «Timeline / Waterfall», мы можем посмотреть все эти

запросы и оценить размеры загружаемых данных.

111
Нажав на каждый файл мы получаем подробные сведения о нем, о его

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

оптимизации данного изображения http://drmax.su/wp-content/uploads/2017/12/snippet-
google2.png,чтобы снизить его размер. Мы можем проверить правильность

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

112
Первый байт сервер начал отдавать через 0,17 секунд, что немного
лучше, чем в среднем по Интернету. Реендеринг страницы начался (в хроме)
на 0,87 секунде, что опять-таки немного лучше, чем в среднем по Интернету.
А вот полная загрузка страницы заняла 9,11 секунд, что на 4 секунды хуже,
чем средние показатели по интернету и может быть большой проблемой для
сайта.
Как мы знаем, только этими 3 метриками измерение скорости

страницы не ограничивается. Поэтому жмем кнопку «More metrics»и
получаем полную раскладку по основным метрикам, отвечающим за
скорость загрузки страницы.

113
Здесь для нас интересен показатель DOM Interactive – это когда

браузер закончил парсить HTML код и выстроил полную DOM конструкцию.
Именно с этого момента начинается возможность взаимодействия
пользователя со страницей сайта, что является важнейшей метрикой
скорости загрузки страницы.
Показатель «Visually Complete» указывает нам, что спустя 3,56 сек,

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

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

dareboost.com.
Анализировать будем на примере главной страницы drmax.su:
https://www.dareboost.com/en/report/d_5b503639e967905afa24e883

114
8.2. Группа показателей Cache policy
Specify a 'Vary: Accept-Encoding' header
Заголовок Vary Accept-Encoding информирует проксирующий сервер,

что необходимо сжать ресурс: как сжатую так и не сжатую версию сайта. Это
способствует обхождению разного рода проблем при работе с прокси-
серверами. Некоторые из них не принимают присутствие заголовка Content-
Encoding.
Решение приведено здесь: https://adminvps.ru/blog/ispravljaem-

zagolovok-vary-accept-encoding/
You do not use too long inline scripts
Данный показатель говорит, что у меня на сайте не обнаружены

излишне крупные инлайновые скрипты.
Для проверки откройте исходный код вашего сайта и проверьте

наличие ненужных инлайновых JS скриптов, например:

115
Решение: Постарайтесь, по возможности, вынести все инлайновые

вставки в отдельные файлы скриптов.
You specify 'Expires' headers
На моем сайте установлено время жизни для всех файлов. Вы можете

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

116
8.3. Группа показателей Number of requests
1 resource is unreachable
Здесь указано, что 1 из ресурсов сайта вернул 404 ошибку. Развернув

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

Ошибка известна и будет устранена.
Group 28 JavaScript files
Метрика предлагаем сгруппировать разрозненные файлы JS скриптов.

Каждый HTTP-запрос влияет на производительность веб-страницы и лучше
запросить уникальный файл размером 50 КБ вместо того, чтобы запрашивать
10 файлов размером 5 КБ.
Развернув метрику мы можем видеть список файлов для группировки.

117
Решение: возможно, стоит сгруппировать и минифицировать отдельные

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

исследуемой странице. Логика работы здесь идентично группировке JS
файлов.
Решение: по возможности выполните группировку разрозненных CSS файлов

в один или несколько.
Resources distribution by domain
DrMax.su подгружает данные с 10 разнообразных доменов.

118
Это не очень хорошо, ведь увеличивается и время загрузки страницы,

а самое главное – снижается надежность сайта, так как сторонние домены
мы не можем контролировать.
Решение: возможно, стоит отказаться от использования данных, скриптов и

файлов с некоторых сторонних ресурсов. Посмотрите, без какой
функциональности можно обойтись, что можно перенести на свой сервер и
пр.
No redirect detected
На странице не найдены 3XX перенаправления. Это хорошо.
You do not use too much “prefetch” on the links
На странице не найдены механизмы предварительной загрузки

данных. Это хорошо для текущей страницы, так как снижает время её
загрузки.

119
Но, если вы хотите повысить удобство пользователя, например

который просматривает картинки в галерее изображений, то такие
механизмы стоит включить. Тем самым, мы ускорим загрузку последующей
страницы. В интернете есть много информации на эту тему, например вот
здесь: https://feeding.cloud.geek.nz/posts/prefetching-resources-to-prime-
browser/
You use CSS sprites
На странице используются CSS скрипты. Если вы еще не перешли на

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

CSS скриптов становится бессмысленным из-за иной модели подгрузки
данных.
None of your images uses only one color
На странице не обнаружены одноцветные изображения. Старой

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

120
8.4. Группа показателей Security
You should use a secure connection (HTTPS)
Сайт не использует HTTPS протокол. Это плохо.
HTTPS гарантирует конфиденциальность и безопасность данных,

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

из ранжирующих факторов в Google.
Не обязательно платить за сертификат, можно воспользоваться

бесплатным от Let's Encrypt. https://letsencrypt.org/
Сегодня многие провайдеры предлагают возможность генерации и

автоматического обновления бесплатных сертификатов непосредственно из
интерфейса администрирования вашего домена.
The Content Security Policy is missing
Отсутствует политика безопасности содержимого. Это плохо, так как

возможны XSS атаки на ваш сайт.
Развернув подсказку вы сможете узнать как настроить политику

безопасности сайта.

121
This page is exposed to "clickjacking" type attacks
Не настроена защита от встраивания вашего сайта в фреймы на

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

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

clickjacking.
Block access to the entire page when an XSS attack is suspected
Защита браузера от XSS атак отключена. Это плохо.
Убедитесь, что браузер пользователя делает все возможное, чтобы

предотвратить XSS атаку. Добавьте в HTTP заголовок переменную "X-XSS-
Protection" со значением "1; mode=block".
Disable the auto detection of resource type
Отключите автоматическое определение типа ресурса. Некоторые

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

122
Для которых принудительно нужно прописать их тип и способ

настройки http заголовка.

123
8.5. Группа показателей Accessibility
52 empty elements can disturb screen readers
Теги <p>, <li>, <button>, <legend>, <caption>, <figcaption> и <quote> не

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

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

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

пустые теги, которые не используются никак, то их следует удалить или
добавить атрибут aria-hidden = "true", чтобы они не отображались.
Explain the purpose of each form field
Объясните назначение каждого поля форы на страницах вашего сайта.

Для этого следует определить тег label для полей.
<label for="name">Fill your name:</label>
<input id="name" type="text" name="name">
В данном случае, для drmax.su – это не ошибка, а всего лишь

особенность моего шаблона. Подходите критически к этой рекомендации.

124
No empty "src" attribute detected
Нет незаполненных атрибутов src на этой странице. Это хорошо.
<noscript> tag detected
Страница использует тег noscript. Это хорошо. При выключенных

скриптах на странице будет выводится замещающий текст.
This page defines a lang
На странице установлен язык сайта. Это хорошо.
Проверку языка сайта мы выполняли ранее с применением Screaming

Frog.
No 'refresh' <meta> tag
Не рекомендуется использование автоматического обновления данных

на странице, указав метатег refresh. Это хорошо.
You specify a consistent label on your links
Вы используете анкорные ссылки на странице. Это хорошо.

125
The main title of the page is the first stated title
Иерархия заголовков на странице не нарушена. Заголовок H1 стоит

первым, перед иными заголовками H2-H6. Это хорошо.
Each form defines a submit button
HTML-формы используются для отправки данных. Для целей

доступности (например, с помощью программы чтения с экрана) все ваши
формы должны включать кнопку отправки.

126
8.6. Группа показателей Compliance
No frameset, frame and noframes tags detected
Не обнаружено использование фреймов на странице. Это хорошо.
Теги <frame> считаются одной из наиболее сложных проблем

оптимизации для поисковых систем. Кроме того, что для поисковых систем
сложно индексировать и сканировать содержимое тегов <frame> (что может
привести к исключению страницы из результатов поиска), использование
этих тегов также отрицательно сказывается на опыте использования сайта.
По возможности старайтесь не использовать теги <frame>.
No Java applets detected
На странице не найдены Java апплеты. Это хорошо.
С 2015 года эта технология считается устаревшей.
Do not use <bgsound> tag
Не используется тег bgsound. Это хорошо, так как он не является

стандартным.
Для добавления аудио / музыки используйте тег audio
<audio src="my-audio-file.ogg" autoplay>

Your browser doesn't support the audio element.
</audio>

127
You do not use links to Word documents
Не используются ссылки на документы Word. Это хорошо.
Не на всех компьютерах установлен Микрософт офис, поэтому лучше

использовать PDF документы.
No deprecated attributes are detected in the <body> tag
На странице не используются устаревшие в HTML-5 теги: alink,

background, bgcolor, link, text и vlink.
Вместо них сейчас используются инструкции CSS.
No BOM (Byte Order Mark) detected
На странице не обнаружен BOM маркер. Это хорошо.
Это маркер последовательности байтов или метка порядка байтов

(англ. Byte Order Mark (BOM)) - т.е. юникод-символ, используемый для
индикации порядка байтов текстового файла. Он вставляется в самое начало
файла при использовании, например, неверных настроек в редакторе
исходного кода.
No Flash resource detected
На странице не используются Flash файлы. Этот показатель мы изучили

ранее.
Silverlight plugin is not used
Не используется плагин Silverlight, который считается устаревшим.
Это хорошо.

128
8.6. Группа показателей Quality
2 IDs are duplicated within your HTML
Для двух разных элементов страницы используется одинаковый ID.
Это плохо.
Использование одного и того же идентификатора на нескольких

элементах может иметь побочные эффекты, особенно во время выполнения
JavaScript или при применении правил CSS.
Необходимо уникализировать идентификаторы.
1 resource does not define its content type
1 ресурс не передает свой тип. Это плохо. В данном случае ошибка

заключена в отсутствии типа ресурса у встроенного фонта.
Желательно настроить HTTP-заголовок Content-Type для него.
28 CSS properties are overridden by shorthands
28 свойств CSS повторно переопределены сокращенной конструкцией.

Это плохо.
Развернув подсказку вы сможете узнать, как более правильно

переопределять свойства и и список CSS файлов и строк в них для
исправления.

129
Однако, если вы не наблюдаете никаких побочных эффектов и

отображение вашего сайта верное и кроссбраузерно, то данный пункт можно
пропустить.
The !important declaration is used 438 times
Декларация !important используется 438 раз. Это слишком много.

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

надо.
21 CSS selectors are too complex
Правила CSS слишком сложны. Использование простых CSS-селекторов

улучшает читаемость и производительность вашего кода. Если есть
возможность, то упростите CSS селекторы как можно более.
Separate the CSS styles from the HTML tags
Вынесите CSS стили из HTML кода.
Рекомендуется группировать стили CSS в <style>тегах или в отдельных

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

130
Развернув подсказку вы сможете узнать, где в HTML коде прописаны

CSS стили, которые необходимо отделить от кода.
 <div class = "vc_empty_space" style = "height: 40px">
 <span style = "color: # 339966;">
 <p style = "text-align: left;">
 <p style = "text-align: left;">
39% of the colors are used only once
Анализируемая страница использует 708 различных цветовых кодов в

собственных файлах CSS, а 274 из них используются только один раз
(некоторые из них могут быть очень близки к другим, например, # FF0000 и
#FE0000).
Рекомендуется попытаться согласовать цвета веб-сайта, чтобы

упростить CSS и избежать несоответствия в пользовательском интерфейсе.
No HTML code is commented
Комментарии позволяют детализировать часть кода и могут помочь

разобраться в структуре страницы. Однако лучшая практика – это удалить из
HTML комментарии.

131
148 selectors are superfluous
Здесь перечислены предположительно избыточные CSS правила. В

большинстве случаев не нужно ничего менять.
41 CSS properties are overridden
Аналогично предыдущему пункту.
You provide a favicon
У страницы есть favicon. Это хорошо.
You do not gzip/deflate PNG images
Вы не используете сжатие PNG изображений. Это хорошо.
Данный тип изображений очень плохо сжимается (архивируется) gzip,

поэтому не нужно тратить ресурсы сервера на это.
The extensions of your resources are consistent
Типы файлов согласованы. Это хорошо.

132
8.6. Группа показателей Browser rendering
3 critical dependencies detected
SPOF зависимость – критическая зависимость от стороннего контента,

который может привести к недоступности страницы или снижению её
скорости открытия при отказе стороннего поставщика.
Весной Роскомнадзор активно банит/банил Google из за Телеграмма.

Все это приводило к крайне низкой скорости работы и/или невозможности
загрузить фонт с Гугла.
Поэтому желательно перенести файлы фонтов, CSS на внутренний

сервер.
Defer parsing of JavaScript
Отложите использование JavaScript на как можно поздний срок.
Используйте один из приведенных ниже методов:
 используйте атрибут async при загрузке;

 используйте атрибут defer ;
 добавьте скрипт в DOM во время события onload;
 убедитесь, что ваши скрипты размещены внизу страницы (в
идеале в самом конце страницы).

133
You should reduce the number of DOM elements
Необходимо использовать менее 1000 элементов DOM на странице

для снижения её сложности и упрощению работы скриптов.
Specify a character set in the response HTTP Header
Не обращать внимание
Your HTML response is not too heavy
На странице приемлемое количество кода. Показатель разбирался

ранее как соотношение контента к коду страницы.
Keep-Alive is enabled
Не обращать внимание.
You do not use CSS @import
Не использовать в стилях внешние таблицы, добавляемые через CSS

@import
You do not use a useless "http-equiv" <meta> tag
Не использовать метатеги http-equiv. Заголовки HTTP более

эффективны, чем мета-теги http-equiv.

134
You don't execute the same script several times
Один и тот же скрипт не исполняется несколько раз на одной странице.

Развернув подсказку вы сможете узнать, как это проконтролировать и
исправить.
The page don't use client-side redirection
Страница не использует перенаправлений на стороне клиента. Это

хорошо.
Your scripts seem to be injected efficiently
Не использовать document.write для добавления скриптов.

135
8.7. Группа показателей Data amount
Reduce the page weight (7.6MB)
Размер страницы слишком велик, замедляет отображение, особенно

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

типам. Например, в случае с drmax.su размер страницы слагается из:
 Изображения: 86,09% от общего веса

 JavaScript: 8,34% от общего веса
 CSS: 2,72% от общего веса
 Шрифт: 1,13% от общего веса
 Тексты: 0,60% от общего веса
 JSON: 0,08%
Наиболее логично начать уменьшение размера страницы с

оптимизации изображений и минификации скриптов.
5 images are resized on browser side
Изображения меняют свой горизонтальный и вертикальный размер на

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

ширину изображений под их вывод в браузере.

136
The PNG format is not the most suitable for 2 of your images
Формат PNG не подходит для 2 изображений. Выбор правильного

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

прозрачности, а также для небольших изображений, имеющих небольшие
детали и цвета.
В данном случае лучше использовать JPG.
Use a better file format for your fonts
Используйте иной, более легкий (меньший по размеру) формат

шрифтов.
Enable compression
Включите сжатие ресурсов для отдельных файлов. См приложение 3.
Minify CSS
Минифицируйте CSS. См. Приложение 4.
Minify JavaScript
Минифицируйте Java скрипты. См. Приложение 4.

137
Optimize your images with WordPress
Правильное сжатие изображений значительно сократит размеры

страницы. См. приложение № 1.
3 domains send 3kB of cookies
Не представляет интереса
All your resources are served from a consistent URL
Ресурсы загружаются с одного и того же адреса. Не допускайте

нескольких адресов для загрузки одного и того же файла.
You do not need to minify the HTML resources
Нет необходимости в минификации HTML кода, он достаточно

компактен.
32 static resources contain 55 bytes of cookies
All your resources have a size < 1MB
Любой из ваших файлов на странице менее 1 Мб. Это хорошо.

138
Lazyloading is set (or not required)
Ленивая загрузка активирована или не требуется на странице. См

приложение № 1.
This page do not send cookies > 100kB
This page does not send too many cookies
2 images use the GIF format properly
2 изображения правильно используют формат Gif. Выбор подходящего

формата может значительно уменьшить вес изображения. См. приложение
№ 1.
Redirects are lightweight
На странице нет редиректов.
The favicon is lightweight
Размер favicon должен быть менее 10kb.

139
8.8. Группа показателей SEO
Your site should use more Open Graph properties
Используйте на странице Open Graph протокол для корректного

расшаривания страницы в социальных сетях.
Минимально необходимые данные:
<meta property="og:title" content="The title" />
<meta property="og:type" content="The type" />
<meta property="og:url" content="http://url.com/" />
<meta property="og:image" content="http://image.jpg" />
This page contains 131 links
Страница содержит 131 ссылку. Анализ этого показателя

рассматривался ранее.
This page defines <h1> and <h2> tags
На странице присутствуют теги H1 и H2. Это хорошо.
This page uses only standard image formats
На странице используются стандартные форматы изображений. Это

хорошо.
К ним относят jpeg, jpg, png, gif, svg, ico и webp.

140
This page specifies a <title> tag
На странице есть тег Title.
Анализ этого показателя рассматривался ранее.
You have defined a <meta> 'description'
У страницы есть мета- описание.
You do not use query strings in the URL
У URL страницы нет параметров.
The words are well separated in this URL
Слова в URL страницы разделены дефисом а не подчеркиванием.

Your <img> tags use an alt attribute, but 1 is empty
У изображений на странице прописаны alt теги. Анализ этого

показателя рассматривался ранее.
Your <meta> 'description' has a good length
Метаописание страницы приемлемой длины. Анализ этого показателя


141
Your <title> tag is an appropriate length
Тег заголовка приемлемой длины. Анализ этого показателя

None of your titles are empty
Ни один из заголовков H1-H3 не пуст. Это хорошо.
robots.txt file is well defined
Файл robots.txt присутствует на сайте. Анализ этого показателя


142
Заключение кейса
Таким образом, dareboost.com позволяет на лету оценить наиболее

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

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

на анализ, выполненный для drmax.su.

143
9. Дополнительные проверки, выполняемые в ручном режиме
1. Анализ сайта и хостинга на отказоустойчивость.
Проверьте, не упадет ли сайт при приходе нескольких посетителей

одновременно.
https://loadimpact.com/
2. Проверка возможности индексации важных областей сайта,

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

которых использовались технологии Flash, Ajax или другие, с индексацией
которых могут возникнуть проблемы.
Откройте сохраненную копию из кэша ПС и изучите страницу.

144
Как мы видим, постгрид, выполненный на ajax не попадает в кэш, что

не очень хорошо и требует дальнейших разбирательств.

145
3. Проверка возможности индексации всех страниц сайта при текущих

инструкциях robots.txt
После корректировки robots.txt необходимо проверить, что все важные

доступны для индексации. Проверка осуществляется вебмастерами ПС,
например:
4.Проверка целесообразности использования <noindex>, nofollow, meta

noindex, meta nofollow
Ошибки в инструкциях индексации могут привести к выпадению

важных страниц из индекса и существенным потерям трафика.
 Необходимо найти не закрытые <noindex>

 Необходимо изучить, какие внутренние ссылки закрыты в
nofollow
 Необходимо изучить, какие внешние ссылки закрыты в nofollow

146
 Необходимо изучить, какие страницы закрыты в meta noindex

 Необходимо изучить, какие страницы закрыты в meta nofollow
После составления списка страниц, на которых используются

инструкции по скрытию индексации, необходимо изучить списки на предмет
ошибок. Контрольные точки:
 Не закрытый <noindex>
 Важные страницы с meta nofollow, meta noindex
 Nofollow на внутренних ссылках
5. Поиск в индексе технических страниц
Проверьте список проиндексированнх страниц и поищите в них

технические страницы, которые необходимо скрыть от индексации,
например:
 Файлы статистики /*_openstat

 Страницы контекстной рекламы или меток /*from=adwords,
/*utm_source=, /*utm_campaign=, /*utm_content=, /*utm_term=,
/*utm_medium=
 Корзина /cart/, /order/
 Страницы сортировки /*sort, asc, desc, list=*
 Страницы поиска /search/
 Страницы авторизации /auth/
 Версия для печати /*printable, /print
 Напоминание пароля /remind_password/
 Регистрация /register/
 Административный раздел - /administrator/
 Кэш страниц /cache/

147
 Модули, подгружаемые на страницы /components/, /plugins/

 Файлы инсталяции CMS /installation/, /installer/
 Логи /logs/
 Файлы /files/
 Аккаунты пользователей /user/
6. Анализ динамики индексации сайта
Проведи анализ динамики индексации сайта
Изучите, какие страницы и по каким причинам выпали из индекса.
Сделайте выгрузку этих страниц и проведите детальный разбор.

148
7. Поиск дублей страниц
Попробуйте забить в урл вашего сайта следующие дубли страниц
 www.site.ru и site.ru
 http:// и https://
 / и /index.php
 /cat/dir/ и /dir/cat/
 /cat/dir/id/ и /cat/id/
 test.site.ru и site.ru/test/
 /?red_id=12345
 /session_id=12345
Устраните найденные дубли

149
8. Проверьте правильность присвоения региональности сайту
9. Проверка страниц на наличие скрытого текста
На странице может быть спамный или важный контент в невидимой

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

Проведите визуальный анализ страницы.
10. Проверьте IP адрес сайта на наличие в спам базах
Проверку можно выполнить тут: https://2ip.ru/spam/

150
11. Проверьте страницы сайта на ошибки HTML
Используйте валидатор: https://validator.w3.org/
12. Проверка наличия телефонов, адресов и др. важной информации в

виде индексируемого текста
Контактная информация должна быть представлена индексируемым

текстом в HTML коде. Проверяйте вручную по выборочным страницам.

151
Приложение 1. Оптимизация изображений.
Прежде всего задайте себе вопрос: действительно ли это изображение

необходимо? Хороший дизайн должен быть простым и не ухудшать
производительность. Лучше всего просто удалить ненужное изображение,
поскольку оно весит гораздо больше байтов по сравнению с HTML, CSS,
JavaScript и другими ресурсами на странице. При этом одно изображение в
нужном месте может заменить длинный текст, поэтому вам нужно
самостоятельно найти баланс и принять правильное решение.
С другой стороны, было проведено ряд исследований, которые

показали, что увеличение количества изображений на странице может резко
повысить число конверсий:
https://calendar.perfplanet.com/2014/images-are-king-an-image-
optimization-checklist-for-everyone-in-your-organization/
Естественно, что это должны быть не «котики» и «собачки», а

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

конверсии на 27%, когда они изменили обычные двумерные
изображения товаров на трехмерные вращающиеся
изображения.
 В тесте А / Б своей целевой страницы Medalia Art обнаружила,
что, замена изображений картин известных художников на
фотографиии самих художников увеличивает коэффициент
конверсии более чем на 95% .

152
 Skinner Auctions провела тест A / B, где они увеличили размер

изображений в своем онлайн-каталоге на 28%. Более крупное
изображение привело к тому, что на 63% больше посетителей
начали процесс оформления заказа.
 Компания Dell так же провела A/B тестирование. Они добавили
крупные фотографии на целевых страницах. При этом они
отметили уменьшение числа отказов на 27% и увеличение
продаж на 36% .
Следовательно, наличие крупных, качественных изображений ведет к

росту конверсии. Однако, всегда необходимо проверять, нельзя ли
достигнуть желаемого результата более эффективным путем:
 Благодаря CSS-эффектам (градиентам, теням и т. д.) и CSS-

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

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

153
Существуют три стандартных формата изображений: GIF, PNG и JPEG.

Кроме них некоторые браузеры поддерживают новые форматы WebP и JPEG
XR, для которых доступно большее сжатие и дополнительные возможности.
1. Изображение должно быть анимированным? Тогда выбирайте

формат GIF. Цветовая палитра GIF состоит всего из 256 цветов.
Это недостаточно для большинства изображений. Кроме того,
формат PNG-8 лучше сжимает изображения с маленькой
палитрой. Таким образом, выбирайте GIF, только если вам
требуется анимация.
2. Нужно сохранить все мелкие детали в самом высоком
разрешении? Используйте PNG. В формате PNG не применяется
сжатие с потерей данных, не считая выбора размера палитры.
Благодаря этому изображение сохраняется в самом высоком
качестве, но весит гораздо больше, чем файлы других форматов.
Используйте этот формат только там, где это необходимо.
3. Если изображение состоит из геометрических фигур,
конвертируйте его в векторный (SVG-) формат!
4. Избегайте текста в изображениях. Его нельзя выбрать, найти или
увеличить. Если текст необходим для создания дизайна,
используйте веб-шрифты.
5. Вы оптимизируете фотографию, скриншот или изображение
похожего типа? Используйте JPEG. В JPEG используется
комбинация сжатия с потерями и без потерь для уменьшения
размера файла. Чтобы выбрать лучшее сочетание качества и
размера изображения, попробуйте установить несколько
уровней качества JPEG.

154
Немного про JPEG. Так как это формат с потерей данных, то с

увилечением уровня компрессии, качество и размер изображения будет
снижаться.
Так на левом изображении, где уровень качества равен 100, размер

изображения составит 275 КБ. На правом изображении уже заметны
артефакты, там уровень качества выставлен в 10, при этом размер
изображения равен 19Кб – т.е. сжатие более чем в 10 раз.
Когда вы выбираете, какую настройку качества выбрать, подумайте о

том, для чего нужны эти изображения:
 Лучшее качество - когда качество намного важнее, чем скорость

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

155
Формат изображения JPEG имеет несколько режимов сжатия. Три

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

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

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

данных EXIF, добавленных цифровыми камерами или редакторами,
оптимизации таблиц Хаффмана изображения или повторного сжатия

156
Возможность PJPEGs предлагать «предварительный просмотр»

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

(примерно) то, что находится в изображении, уже при получении части
файла.
Прогрессивный формат сжатия (PJPEG) лучше работает на крупных

изображениях. При этом экономия может составлять 2-10% от базового
формата сжатия.
Существуют еще некоторые настройки сжатия JPEG – но с ними вам

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

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

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

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

157
многие сайты совершают серьезную ошибку. Они размещают крупные

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

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

здесь:
https://imageoptim.com/versions.html
Ранее я еще рекомендовал онлайн софт для пакетного сжатия

изображений:
https://kraken.io/web-interface
В целом таких сервисов – десятки.
Как понять, нужно мне производить оптимизацию изображений или

пусть все остается как есть? Да очень просто – запустите тест:
https://www.webpagetest.org/
Посмотрите раздел «Сжатие изображений» в отчете.

158
Здесь будут отображаться изображения, которые могут быть сжаты

более эффективно, и общая экономия на размере файла. Так, например, для
мордочки drmax.su:
Найдено 21 изображение общим размером 5 Mb, которое можно

ужать при определенных условиях до 631Kb – т.е. экономия составит около
87%. Ну и ниже будут приведены примеры обработки всех изображений

159
Таким образом, некоторая работа по оптимизации изображений

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

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

повышенной плотности. Бывают 2-х кратная плотность, как на скрине, а

160
бывает что и трех-кратная плотность. А так как у меня их нет, то они получают
404 ошибку. Что это такое вообще и как с этим жить дальше?
В данном случае происходит запрос на предоставление изображения

на основе размера / плотности экрана с использованием <picture>/ <img
srcset>.
Очень удобно, когда браузер способен выбирать, какой формат

изображения отображать с помощью тега <picture>.
Тег <picture> использует несколько <source> элементов и с одним

тегом <img>, который является фактическим DOM - элементом, содержащим
ссылки на изображения. Браузер циклически перебирает эти ссылки на
изображения и отображает нужную картинку при совпадении условий. Если
тег <picture> не поддерживается браузером, то будет отображена картинка в
теге <img>.
Атрибут srcset расширяет функциональные возможности элемента img.

Благодаря ему вам будет проще назначать изображения с учетом
параметров устройства. Как и в случае с image-set (функция CSS), атрибут
srcset позволяет браузеру выбирать наиболее подходящее изображение в
зависимости от характеристик устройства.
Например, использовать изображения 2x на экране 2x и,

потенциально, изображения 1x на устройстве 2x при ограниченной
пропускной способности сети:
<img src="photo.png" srcset="photo@2x.png 2x" ...>
Если браузер не поддерживает атрибут srcset, по умолчанию файл с

изображением импортируется с помощью атрибута src. Вот почему так
важно включать изображение 1x, которое может отображаться на любых

161
устройствах, независимо от их свойств. Если браузер поддерживает атрибут

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

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

характеристик устройства (эффект art direction), воспользуйтесь элементом
picture. Элемент picture задает декларативное решение для обеспечения
нескольких версий одного изображения в зависимости от различных
характеристик устройства: размера, разрешения, назначения и т. д.
Используйте элемент picture, если у источника изображения несколько

вариантов плотности пикселей, а также если в рамках отзывчивого веб-
дизайна для некоторых типов экранов назначаются изображения с
различающимися характеристиками. Как и в случае с video, вы можете
указать несколько элементов source и назначать разные файлы изображений
для разных медиазапросов или форматов изображений.
<picture>
<source media="(min-width: 800px)" srcset="head.jpg, head-2x.jpg
2x">
<source media="(min-width: 450px)" srcset="head-small.jpg, head-
small-2x.jpg 2x">
<img src="head-fb.jpg" srcset="head-fb-2x.jpg 2x" alt="a head
carved out of wood">
</picture>

162
В приведенном выше примере при ширине браузера не менее 800

пикселей будет использован формат head.jpg или head-2x.jpg (в зависимости
от разрешения экрана устройства). Если ширина браузера от 450 до 800
пикселей, применяются форматы head-small.jpg или head-small-2x.jpg (также
в зависимости от разрешения экрана устройства). Если речь идет о ширине
экрана менее 450 пикселей и устройстве с нисходящей совместимостью,
элемент picture поддерживаться не будет. В этом случае для вывода
изображения на экран браузер использует элемент img (он должен быть
включен).
Если финальный размер изображения неизвестен, довольно сложно

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

плотность пикселей. Вместо этого вы можете определять размер
обрабатываемого изображения, добавив дескриптор width. Это позволит
браузеру автоматически вычислить оптимальную плотность пикселей и
выбрать корректное изображение для загрузки.
<img src="lighthouse-200.jpg" sizes="50vw"

srcset="lighthouse-100.jpg 100w, lighthouse-200.jpg 200w,
lighthouse-400.jpg 400w, lighthouse-800.jpg 800w,
lighthouse-1000.jpg 1000w, lighthouse-1400.jpg 1400w,
lighthouse-1800.jpg 1800w" alt="a lighthouse">
Выше приведено изображение, которое занимает половину ширины

области просмотра (sizes="50vw") и зависит от ширины браузера и его
соотношения логических и физических пикселей. В результате браузер может

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

размера.
В некоторых случаях размер или изображение могут изменяться в

зависимости от точек останова, заданных в шаблоне сайта. Например, вам
нужно будет, чтобы на маленьких экранах изображение занимало всю
область просмотра, а на экранах более крупного формата достаточно будет
небольшой части.
<img src="400.png"
sizes="(min-width: 600px) 25vw, (min-width: 500px) 50vw,
100vw"
srcset="100.png 100w, 200.png 200w, 400.png 400w,
800.png 800w, 1600.png 1600w, 2000.png 2000w" alt="an
example image">
В приведенном выше примере атрибут sizes определяет размеры

изображения с помощью различных медиазапросов. Если размер окна
браузера превышает 600 пикселей, изображение будет занимать 25%
области просмотра. При размере браузера от 500 до 600 пикселей это
значение увеличивается до 50%, а при размере меньше 500 пикселей
изображение становится полноэкранным.
Поехали дальше. Существует мнение, что спрайты (CSS-спрайтинг)

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

это проверенная и отработанная технология, применяемая на большинстве

164
коммерческих сайтов. Однако все это было справедливо в эпоху HTTP/1.0 и

HTTP/1.1. Если ваш сервер настроен на новый протокол HTTP/2, то скорее
всего использование спрайтов не даст особого преимущества из за
доступности параллельной загрузки изображений. В целом –
экспериментируйте, тестируйте и пробуйте.
Следующий путь оптимизации – использование отложенных

изображений (ленивая загрузка, Lazy Loading).
Данная техника полезна для «некритических» изображений, как

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

необходима JavaScript библиотека.
Преимущества ленивой загрузки таковы:
1. Сокращение числа запросов к серверу, количества передаваемых

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

165
Но есть и ряд ограничений. Например, необходимо избегать

«ленивой» загрузки для видимой части экрана – т.е. над уровнем сгиба.
Для интеграции «ленивой» загрузки на сайт есть ряд плагинов и

расширений для большинства распространенных CMS.
Так например, для Wordpress их несколько десятков:
Можно использовать и отдельные библиотеки, например:
https://github.com/aFarkas/lazysizes
Никаких особых настроек не требуется, достаточно подключить

библиотеку на страницу:
<script src="lazysizes.min.js" async=""></script>
И можно приступать к работе. Пример ленивой загрузки обычного

изображения:
<img data-src="image.jpg" class="lazyload" />
«Ленивая» загрузка адаптивного варианта изображения

166
<img
data-sizes="auto"
data-src="image2.jpg"
data-srcset="image1.jpg 300w,
image2.jpg 600w,
image3.jpg 900w" class="lazyload" />
Обратите внимание, что здесь в data-src загружается image2.jpg,

который является временным заполнителем места для картинки.
Ну и пример ленивой загрузки видео
<iframe frameborder="0"
class="lazyload"
allowfullscreen=""
data-src="//www.youtube.com/embed/ZfV-aYdU4uE">
</iframe>
Еще больше разнообразных вариантов ленивой загрузки можно

посмотреть здесь:
http://afarkas.github.io/lazysizes/#examples
На этом заканчиваем с оптимизацией изображений.

167
Приложение 2. Проверка наличия мобильной версии сайта
Проверить, что Ваш сайт корректно отображается на мобильных

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

мобильного устройства. Зайдите в Меню  Дополнительные инструменты 
Инструменты разработчика (Ctrl+Shift+I) и в левом верхнем углу переключите
на мобильный вид:
или нажмите сочетание клавиш Ctrl+Shift+M.
Вы можете просмотреть ваш сайт при любых разрешениях экрана

мобильного устройства (1), при этом задачей оптимизации сайта под

168
мобильные устройства является корректное отображение необходимых

разделов сайта на маленьких экранах мобильных устройств (2).
Так – же, быстро оценить как выглядит дизайн вашего сайта под
различные разрешения можно здесь:
http://mattkersley.com/responsive/
Далее выполните проверку оптимизации вашего сайта под мобильные

устройства:
https://search.google.com/test/mobile-friendly

169
Приложение 3. GZIP сжатие
GZIP - это стандартный компрессор, который может быть применен к

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

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

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

методов оптимизации, о котором многие забывают. Большинство веб-
серверов будут уменьшать размер контента самостоятельно. Вам просто
надо проверить, настроено ли на сервере сжатие всех типов ресурсов, для
которых эффективно применение GZIP.
Проверить включено ли у вас сжатие GZIP можно здесь:
http://www.gidnetwork.com/tools/gzip-test.php
http://www.whatsmyip.org/http-compression-test/
Запомните, что сначала файлы необходимо минифицировать, а затем

уже их сжимать – так достигается минимальный размер файлов.
Настройка GZIP сжатия очень проста и может выполняться

несколькими способами.

170
Самое простое – если такая настройка присутствует на вашем хостинге.
Например на хостинге с установленным ISP – manager сжатие включается:
WWW  WWW домены
Далее выбираем требуемый домен из списка и переходим в

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

средствами CMS, тогда при изменении / добавлении материалов кэш будет
принудительно перестраиваться, в отличии от серверного кэширования, где
можно задать только время жизни кэша. Однако это вполне приемлемый
путь для необновляемых сайтов, либо сильно нагруженных серверов, о чем
поговорим ниже.
Следующий способ – можно включить GZIP сжатие через .htaccess.

171
В современных версиях Apache, gzip включается через mod_deflate.

Пропишите в .htaccess следующее:
AddOutputFilterByType DEFLATE text/plain

AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
Чтобы включить Gzip в Nginx, добавьте эти строки в конфигурацию

сервера:
server {
....
gzip on;
gzip_disable "msie6";
gzip_types text/plain text/css application/json application/x-
javascript text/xml application/xml application/xml+rss
text/javascript application/javascript;
}
Следующий момент такой. Необходимо понимать, что само сжатие на

сервере хостинга занимает некоторое время. Чем выше уровень сжатия
установлен, тем больше затрачивается на это времени.
Тем самым ухудшается показатель TTFB (время загрузки первого

байта). С точки зрения Google, время загрузки первого байта является более
надежным индикатором скорости работы сайта, чем полная загрузка
страницы. То есть TTFB – это показатель задержки в передаче данных между
браузером и сервером и показатель степени загрузки сервера, в то же время
это и показатель скорости генерации контента CMS сайта.
Особенно ярко это проявляется на слабых серверах при высокой

загрузке (количестве посетителей). Здесь весь выигрыш от быстрой загрузки
сжатых файлов может съедаться очень длительным ожиданием загрузки.
Именно здесь может помочь включение серверного кэширования с

172
небольшим временем жизни КЭШа. Причем чем реже вы обновляете сайт,

тем больше выставляйте время кэширования. Так вы можете снизить
нагрузку на сервер и поднять показатель TTFB.
Еще одним способом снижения нагрузки является ручное

предкэширование. Вы можете самостоятельно, с использованием
архиватора, сжать ваши .css и .js файлы из шаблона в формат .gz и заново
залить их на сервер.
Например было style1.css, стало style1.css.gz.
Далее прописываете в .htaccess следующие перенаправления:
# Перенаправление на gzip файлы

AddEncoding gzip .gz
<FilesMatch "\.js.gz$">
ForceType text/javascript
Header set Content-Encoding: gzip
</FilesMatch>
<FilesMatch "\.js$">
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} !".*Safari.*"
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{REQUEST_FILENAME}.gz -f
RewriteRule (.*)\.js$ $1\.js.gz [L]
ForceType text/javascript
</FilesMatch>
<FilesMatch "\.css.gz$">
ForceType text/css
Header set Content-Encoding: gzip
</FilesMatch>
<FilesMatch "\.css$">
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} !".*Safari.*"
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{REQUEST_FILENAME}.gz -f
RewriteRule (.*)\.css$ $1\.css.gz [L]
ForceType text/css
</FilesMatch>
При статическом сжатии файлов сервер избавляется от лишней

нагрузки и не тратит время на сам процесс сжатия. Однако после изменения
файлов .css и .js придется сделать их новые gzip копии.

173
Приложение 4. Минификация контента
Удалив все ненужные ресурсы, перейдем к следующем шагу -

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

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

размеров файлов css, js и html. Удаляются переводы строк, комментарии,
лишние отступы и пробелы, иногда сокращаются имена переменных. Таким
образом достигается ускорение загрузки сайта и оптимизация запросов. Это
позволяет сэкономить 10...20% от оригинального размера файла.
Существует масса продвинутых CSS, JS и HTML минификаторов, начиная

от простых и заканчивая многопроходными монстрами. Вот небольшой
перечень бесплатных CSS минификаторов:
http://www.cssdrive.com/index.php/main/csscompressor/
https://www.cleancss.com/css-minify/
https://csscompressor.com/
https://www.askapache.com/online-tools/compress-css/

174
Аналогично легко можете найти онлайн минификаторы и для HTML и

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

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

расположен на хосте или встроен в CMS в виде плагина и он каждый раз
минифицирует файлы и кэширует их на какой то срок.
Очень интересный хак для WordPress предложил Артем Малков
https://artem-malcov.ru/haki/minifikaciya-ishodnogo-koda-v-wordpress-na-php
Для того чтобы сделать минификацию кода на WordPress, предпримем

следующее: подключимся к сайту по FTP. Откроем файл functions.php в папке
вашей темы (/wp-content/themes/) и в самый верх, сразу после <?php,
вставим:
function sanitize_output($buffer) {
$search = array('/\>[^\S ]+/s', '/[^\S ]+\</s', '/(\s)+/s', '//');
$replace = array('>', '<', '\\1', '');
$buffer = preg_replace($search, $replace, $buffer);
return $buffer;
ob_start("sanitize_output");
Сохраняем изменения и отправляем файл обратно на сайт. Теперь,

если вы посмотрите исходный код вашего сайта, то увидите принцип работы
минификации.

175
Так же у него есть хаки по минификации для DLE:
https://artem-malcov.ru/haki/minifikaciya-ishodnogo-koda-v-dle-na-php
и Bitrix:
https://artem-malcov.ru/haki/minifikaciya-ishodnogo-koda-v-bitrix-na-php
Имеется так-же прекрасный хак по минификации CSS и Java скриптов

на PHP:
https://artem-malcov.ru/moduli_i_skripty/minifikaciya-js-i-css-faylov-na-php
Для всех развитых CMS есть как отдельные плагины и расширения для
минификации, так и целые «комбайны», включающие в себя кэширование
запросов, минификацию, кэширование страниц, их архивацию, работу с CDN
и прочее.
Например для WordPress есть сотни плагинов для минификации

контента:
https://wordpress.org/plugins/search/Minify/
и плагинов по кэшированию, в котрых минификация тем или иным

встроена:
https://wordpress.org/plugins/search/cache/

Язык

(Drmax) Аудит Сайта Своими Руками

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

(Drmax) Аудит Сайта Своими Руками

Оригинальное название:

Загружено:

Авторское право:

Доступные форматы

1

Drmax.su // Аудит сайта своими руками. ч.1. «Технический аудит»

Скачано с сайта https://sharewood.biz/ - Присоединяйся!

Аудит сайта своими

Скачано с сайта https://sharewood.biz/ - Присоединяйся!

Скачано с сайта https://sharewood.biz/ - Присоединяйся!

4.10. Дублирование метатега Description .......................................................................................... 74

Скачано с сайта https://sharewood.biz/ - Присоединяйся!

На сегодняшний день существует уже более двух тысяч факторов

По значимости, примерно 30-40% занимает группа ссылочных

Технический аудит сайта, которому посвящена настоящая книга

Огромная прелесть технического совершенствования сайта

Автор постарался сделать пошаговые инструкции для анализа всех

Желаю Вам удачи!

Скачано с сайта https://sharewood.biz/ - Присоединяйся!

Другие мои книги:

SEO Монстр 2018.

SEO Гуру 2018.

Если Вам необходим профессиональный аудит сайта,

Скачано с сайта https://sharewood.biz/ - Присоединяйся!

Перед проведением аудита необходимо максимально снизить влияние

Рекомендую воспользоваться для этой процедуры бесплатной версией

Здесь можно настроить какие куки следует удалять, а какие добавить в

Скачано с сайта https://sharewood.biz/ - Присоединяйся!

Следующим шагом осуществляем настройку Screaming Frog – нашей

Программа бесплатна для аудита сайтов до 500 URI включительно.

Для начала настроим краулер (паука)программы.

На закладке основных настроек устанавливаем значения следующим

Скачано с сайта https://sharewood.biz/ - Присоединяйся!

На закладке «Reendering» мы выбираем как краулер (паук) программы

Скачано с сайта https://sharewood.biz/ - Присоединяйся!

Необходимо отметить, что Google с весны 2018 года умеет разбирать и

В то же время, Яндекс не может сканировать и индексировать

Поэтому в настройках, в большинстве случаев необходимо указать

Скачано с сайта https://sharewood.biz/ - Присоединяйся!

Далее подключаемся к API Google Analytics и Google Search Console для

На этом подготовка завершена. Запускайте краулер кнопкой «Start».

Скачано с сайта https://sharewood.biz/ - Присоединяйся!

В последнее время я начинаю любой технический аудит с проверки

Проверьте «забаненность» (блокировку) вашего сайта по IP и

Обратите внимание, что использование платных, а уж тем более

CDN, как правило, блокируют по диапазонам адресов, поэтому

Убедитесь в том, что ваш сайт доступен у пользователей различных

Скачано с сайта https://sharewood.biz/ - Присоединяйся!

2.2. Проверка robots.txt

Убедитесь, что у вашего сайта есть robots.txt и он настроен корректно.

Если файл robots.txt написан с ошибками, это может привести к

Robots.txt – служебный файл, который находится в корневом каталоге

Robots.txt в большинстве случаев используется для исключения

Правильное манипулирование robots.txt позволяет перенаправить

Файл robots.txt должен:

 располагаться строго в корне сайта,

Скачано с сайта https://sharewood.biz/ - Присоединяйся!

 число директив (команд) не должно превышать 1024,

В соответствии со стандартом перед каждой директивой User-agent

Символ # предназначен для описания комментариев. Все, что

Если файл robots.txt отсутствует, не является текстовым или на запрос

Robots.txt должен содержать обычный текст в кодировке UTF-8,

Выполняются только действительные записи, остальное содержание

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

Отметка последовательности байтов (BOM) в начале файла robots.txt