Технический аудит сайта: пошаговая инструкция для тех, кто не готов переплачивать

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

При этом важно понять 2 момента:

1. Технический аудит – это не выгрузка из Netpeak Spider или Screaming Frog. Хотя именно их чаще всего и выдают за аудит на биржах фриланса. Это софт, который позволяет собрать часть (!) информации, не более.
2. Пишите в аудит только то, что требуется исправить, а не все что вы проверили. Лучше это будет 1-2 листа реально важных рекомендаций в виде ТЗ для программиста, чем 10-20 листов описания того, что вы проверили.

Второй пункт спорный. Если вы пришлете заказчику 5 правок по технической части и напишите, что все остальное в порядке, у него точно возникнет вопрос – что вы имеете ввиду под «все остальное»? Может вы всего 5 параметров проверили, а может 50…

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

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

Склейка зеркал

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

Перед аудитом уточняем у заказчика, есть ли у сайта зеркала. Чтобы в случае обнаружения дублей сразу понимать, это зеркала, которые нужно проверить и склеить при необходимости, или кто-то скопировал сайт и с этим нужно бороться. Второй вариант мы будем разбирать, но не в рамках технического аудита. А вот если заказчик все-таки делал зеркала – это нужно знать. Но это бывает редко, поэтому проверяем только на http/https, www и слеши.

Порядок действий:

1. Берем любую страницу сайта.

2. Составляем список возможных адресов с http/https, с www и без, со слешем на конце и без. Пример:

3. Проверяем ответы сервера для этих адресов (в статье по ссылке выше все это расписано). В зависимости от результатов проверки пишем ТЗ для программиста.

Если зеркала склеены

То есть, один адрес отдает код 200, а остальные 301 редирект на главное зеркало. Тогда никаких действий не требуется.

Если есть цепочки редиректов

В таком случае пишем программисту следующее:

Если зеркала склеены частично

Например, редиректы с http на https настроены, а с www на адреса без www – нет. В таком случае пишем программисту, чтобы настроил недостающие 301 редиректы на главное зеркало и указываем с каких адресов на какие.

Если зеркала не склеены

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

HTTPS

Не знаете, что такое HTTPS, SSL, как они работают и какой протокол лучше для сайта? Тогда делаем еще одну паузу и читаем статью по ссылке. А уже после этого проверяем наличие HTTPS и правильно ли он настроен.

Вариант 1

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

Вариант 2

Если сайт доступен только по HTTP и при этом он новый (после запуска прошло несколько дней/недель), пишите в ТЗ для программиста, что нужно перенести сайт на HTTPS. Но с новыми сайтами редко приходят на продвижение, так что это скорее для справки.

Если сайт доступен только по HTTP и уже имеет позиции/трафик, перенос нужно согласовать с владельцем и делать под контролем SEO-специалиста. Иначе есть риск потери имеющихся позиций и трафика. В таком случае пишете в отчете по техническому аудиту следующее:

Если делаете аудит для себя – планируйте переход на HTTPS, вы все равно к этому придете.

Дополнительная проверка по желанию

Правильность настроек сайта при переходе на HTTPS обычно проверяют в момент проведения этих работ. Поэтому здесь редко бывают проблемы. Но случаи бывают разные, а проверка через SSL Checker займет пару минут. Почему бы и не посмотреть… Гуглите «SSL Checker», берете первый попавшийся и проверяете сайт через него. Для сайта PROSUVER, который работает на https, результат проверки выглядит так:

или так:

Если при проверке у вас также все зеленое – все ок. Если нет – нужно смотреть, в чем именно проблема. Не разбираетесь – и не нужно, напишите тогда в ТЗ программисту, что при проверке таким-то чекером вы получили такой-то результат. И нужно посмотреть, что это за проблемы.

Robots.txt

Практически любой чек-лист технического аудита сайта рекомендует проверить robots.txt. Но вот проблема – как его проверить новичку, который только учится делать аудиты… Ответ прост – никак. Чтобы действительно проанализировать robots, нужен опыт. И уж тем более нужен опыт, чтобы прописать для него недостающие директивы. Но нужно же с чего-то начинать. Так что попробуем.

Проверяем его наличие

Robots.txt – это файл, который показывает поисковым системам, что именно на сайте им разрешено обрабатывать. Найти его можно по адресу:

Обратите внимание – адрес может быть только таким. Подставляйте свой домен и проверяйте. Если страница будет недоступна, значит robots.txt отсутствует. В таком случае пишите в ТЗ, что его нужно добавить. При его наличии вы увидите страницу такого типа:

Есть ли ссылка на карту сайта

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

Доменное имя, естественно, должно быть сайта, который вы проверяете. А вот последняя часть адреса может быть разной. Я привел 2 варианта, но могут быть и другие. Если такой строки нет – пишите программисту:

При этом url карты сайта вы не указываете. Не понятно, создана ли она вообще и какой у нее будет адрес (а это зависит еще и от способа создания). Оставьте это программисту.

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

Смотрим содержимое

Здесь сложнее. На скрине выше у нас есть блок, который начинается с «User-agent: *». Звездочка обозначает, что правила ниже распространяются на все поисковые системы. А затем идет список директив Allow и Disallow, которые показывают, что поисковому роботу сканировать можно, а что нельзя. Проверить их без опыта сложно. Поэтому пойдем по другому пути.

Спросите у заказчика, какая у сайта CMS (система управления контентом, она же «движок сайта»). Затем погуглите – правильный robots.txt для… и указываете какой CMS. На скрине выше – это robots.txt для WordPress. Для других движков или для самописных сайтов он будет другим.

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

А вот если в рекомендуемом варианте вы видите 15-20 строк, а по факту их 3 – вот тогда нужно разбираться и вникать более детально. Опытный SEO-специалист на данном этапе составит правильный robots.txt и приложит его к ТЗ с правкой «Нужно заменить». В вашем случае есть варианты:

1. Ищете информацию в интернете и разбираетесь. Базу поймете быстро. А вот составить правильный вариант все равно будет сложно.
2. Спрашиваете совета у более опытного SEO-специалиста. Несколько таких обсуждений и начнете понемногу разбираться.
3. Пишете в ТЗ, что рекомендуемый robots.txt должен быть таким… (ссылаетесь на базовый вариант для вашего движка), а сейчас он такой… (указываете текущий) и спрашиваете у программиста, почему так. А потом уже в процессе обсуждения приходите к какому-то решению.

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

Что еще может сбить вас с толку:

• Может быть прописан «User-agent: *» с блоком директив. А ниже «User-agent: GoogleBot» и опять список директив. Таких повторов может быть 3 и даже более. Это нормально. Некоторые предпочитают дублировать директивы для каждой ПС отдельно или есть необходимость писать разные правила для разных ботов.
• Встречается директива «Host». Она уже не нужна. Можно убирать.
• Если видите «Clean-param:» – обычно это не требует корректировок. Это, скорее, показатель, что роботс на этом сайте делал кто-то с пониманием процесса. Не всегда, но чаще именно так.

Sitemap.xml

Sitemap.xml – это карта сайта для поисковых систем, чтобы они понимали какие страницы есть на сайте и что нужно индексировать. Для PROSUVER она доступна по адресу:

Выглядит так:

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

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

Проверяем наличие

Пожалуй, это основная задача для новичков. Нужно чтобы карта хотя бы была. Как ее искать?

Начните с простого – немного выше я дал два адреса, меняйте домен и проверяйте по ним. Первый – это стандартный путь, второй – для карт, которые были сгенерированы плагином Yoast SEO (часто встречается). Еще вариант – в этих url-адресах вместо sitemap.xml, подставьте sitemap.xml.gz. Иногда карты могут архивироваться. Если ничего не нашлось – не тратьте время, спросите у заказчика, делалась ли карта. Если да – попросите адрес, если нет – пишем в технический анализ сайта:

Проверяем ссылки

Если вы увидите карту на 10 000 url-адресов, предложение проверить ее содержимое может показаться вам нереальной задачей. Но проверять все и не нужно. В идеале должно быть так:

• не должно быть дублирования адресов;
• в sitemap.xml содержатся только страницы, которые должны быть проиндексированы.

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

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

• Главная: https://prosuver.ua/ru/
• Раздел: https://prosuver.ua/ru/blog/
• Статья: https://prosuver.ua/ru/blog/seo/h1-h6/
• Страница: https://prosuver.ua/ru/contacts/

Разделов, страниц и статей на сайте может быть много. Например, 10 страниц, 400 статей и 20 разделов/подразделов (цифры просто для примера). И все это, мы хотим видеть в индексе ПС. Значит они должны быть включены в sitemap.xml. Но не проверять же их все… Поэтому берем по одной странице каждого типа, как в списке выше и через поиск ищем в sitemap. Нашли? Все ок. Нет – пишем программисту страниц какого типа не хватает и просим переделать карту.

Это была проверка на нужные страницы. Что касается не нужных – на сайте могут быть, например, страницы тегов (часто можно увидеть после статьи: #SEO, #Аудит) или еще какие-то страницы, которые владелец или вы закрываете от индексации. Нужно также взять по 1 странице каждого типа (если их несколько) и проверить их наличие в карте. Их там быть не должно. Если есть – пишем правку.

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

404 ошибка

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

Если откроете эту ссылку, увидите страницу блога с анонсами постов. А теперь представьте, что кто-то порекомендовал блог Prosuver на форуме, но ошибся в ссылке и написал «/blog8/». Случайно добавил цифру или букву.

Другой пример – мы сами делали ссылку с одной статьи на другую и ошиблись при вводе url. Или у нас была на сайте статья, мы ее удалили, но ссылки на нее остались как на нашем сайте, так и на других площадках в интернете.

Вопрос – что должно произойти при попытке открыть такую страницу? А должно произойти две вещи:

1. Сервер должен отдать ответ – 404

И это первое что нужно проверить. Гуглите любой «сервис для проверки ответа сервера», вбиваете несуществующий адрес. Я для этого просто добавил цифру 8 в конце, но лучше вместо /blog/, вставить что-то подобное /hkajkja3jhke8k/. И смотрите результат:

Если 404 – все отлично, ничего делать не нужно. Если 200 – пишете правку программисту:

2. Страница 404 ошибки должна быть

Если вы откроете несуществующую страницу на этом сайте, то увидите вот такое:

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

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

Скорость загрузки

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

Чем проверять

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

Что проверять

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

На что смотреть

В результате проверки вы увидите:

Первая стрелка – это просто адрес страницы, которую проверяете. А смотрите вы на нижнюю стрелку (там где у меня цифра 100). Но обратите внимание, что есть вкладки – «Мобильные устройства» и «Компьютер». Вам нужно посмотреть результат проверки для обоих вкладок. Потому что скорость на мобильных и ПК может очень сильно отличаться.

В каком случае писать правку

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

• 90-100 баллов (зеленая зона) – все отлично.
• 50-89 баллов (желтая зона) – нормальный результат, правка не обязательна, но рекомендуете ускорить. Особенно, если цифра ближе к 50, а не к 80.
• 0-50 (красная зона) – пишете правку на ускорение.

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

Бывают ситуации, когда у вас скажем 60 баллов, и почему бы не ускориться, но смотришь конкурентов, а вы по скорости загрузки лучший. Тогда зачем тратить на это время сейчас, если можно делать что-то более важное. А бывает наоборот, у вас 75, боретесь за ТОП 3, а там сайты все от 90 баллов (редко, но бывает). Тогда нужно подтягиваться до их уровня.

Рекомендации при попадании в оранжевую зону будут выглядеть примерно так:

Canonical

Выше мы уже обсудили, что зеркала – это копии сайтов и их нужно склеивать через 301 редирект. Помимо копий сайта, могут быть копии (дубли) страниц внутри сайта. Бороться с ними можно разными способами. Один из способов – прописать rel=«canonical».

Например, есть страница, которая доступна по 3 разным url-адресам. Если вы выберите один из них за основной и потом пропишете на всех 3 страницах rel=«canonical» на «основную», тогда поисковые системы будут понимать, что в результатах поиска должна быть только она, а остальные – это дубли, и вы это показываете, а не пытаетесь продвинуть все 3 страницы сразу.

Как проверить

Устанавливаете расширение для Google Chrome – Seo Meta in 1 Click. Открываете в браузере проверяемые страницы. Также возьмите по 1 странице каждого типа. Затем нажимаете на значок расширения и смотрите вот эти строки:

Если напротив url и canonical прописан адрес и он совпадает – все ок, правки не нужны. Каждая страница и должна иметь каноникал на себя.

Если прописан только url (он в любом случае будет прописан), а напротив canonical ничего нет, пишете правку:

Если адреса не совпадают – нужно разбирать почему. И в зависимости от этого писать правку. Причин может быть 2:

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

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

Мобильная версия

Практически все клиенты, которые у меня сейчас в работе имеют процент трафика с мобильных устройств более 50%. А у некоторых он превышает 80%. При этом начинающие SEO-специалисты, делая проверку сайта на технические ошибки, часто смотрят только версию для ПК. Где работают, там и смотрят… И это проблема. Мобильную версию проверять обязательно!

Адаптивный сайт нужно проверить для разных разрешений экрана и разных браузеров. Для отдельной мобильной версии, нужно дополнительно проверить alternate, canonical, robots, xml-карту. Но статья рассчитана на новичков, поэтому делаем только простой анализ, который зачастую еще и очень эффективный.

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

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

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

И второй момент – сайт на мобильном устройстве должен иметь те же блоки, тексты, кнопки, ссылки и другие элементы, как и версия на ПК. Например, если на ПК после этой статьи вы видите блок «Похожие статьи» с четырьмя карточками, то и на телефоне должно быть так же.

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

После этого повторяете проверку на том же устройстве, но в другом браузере. Какие браузеры проверять? Самый простой вариант – наиболее популярные (Chrome, Safari, Samsung). А если есть доступ к аналитике, тогда лучше посмотреть какими браузерами пользуется большая часть посетителей сайта и проверять на них. Затем берете планшет, если есть под рукой, и повторяете проверку. Мало того, по возможности это нужно сделать для устройств и на iOS, и на Android.

Hreflang

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

В чем проблема мультиязычных сайтов

Смотрим на примере PROSUVER. На момент написания статьи у сайта есть украинская и русская версии. То есть, каждая страница представлена на 2 языках. Если просто сделать перевод, ПС может воспринять эти страницы как дубли. Чтобы этого не было, нужно «сказать» поисковым системам, что это не дубли, а разные языковые версии. Для этого в HTML код страниц нужно добавить специальный атрибут – hreflang.

Что такое hreflang

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

• link rel=«alternate» показывает ПС, что есть альтернативная версия страницы;
• hreflang=«uk-UA» – указывает язык и регион альтернативной версии;
• href=«https://prosuver.ua/» – ее url-адрес.

Как проверять

Открываете исходный код страницы. Через поиск находите «hreflang». Смотрите сколько таких строк и что в них.

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

Второе – смотрите что прописано в кавычках после hreflang. В нашем случае – это «uk-UA» и «ru-UA». Украинский и русский языки для Украины. Может быть написано так, а может:

• «uk» – украинский язык, для всех регионов;
• «ru» – русский язык, для всех регионов.

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

Ваша задача – посмотреть какие языки есть на сайте и на какие регионы он ориентирован. После этого проверить правильно ли указаны языки и регионы. Например, если вы делаете страницы на украинском отдельно под Украину и Польшу, там будет «uk-UA» и «uk-PL». Пример правки:

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

ЧПУ

Этот пункт смотрите только в том случае, если вам нужно провести технический аудит сайта на этапе создания или сразу после запуска. Если он проиндексирован и имеет позиции/трафик – ничего делать не нужно.

В чем проблема

Если при создании сайта не настроить ЧПУ, url-адреса будут формироваться автоматически. Они могут содержать буквы: цифры и символы (=, &, ?) и выглядеть примерно так: https://site.com/?p=123. И это еще очень простой вариант.

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

ЧПУ – это так называемые человекопонятные URL. Это когда у нас для страницы с мета-тегами в адресе будет «meta-tags» или «meta-tegi». То есть, траслит латинскими буквами или перевод на английский. Пример:

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

Как проверять

Если ЧПУ настроены – это видно по любой внутренней странице. Но лучше откройте несколько страниц разного типа и посмотрите их url-адреса. Если там транслит или перевод на английский – все ок. Если непонятно что, пишите:

Это не касается страниц фильтров на сайтах интернет-магазинов. Там могут быть нюансы. Но разделы, товары, услуги, статьи – должны быть ЧПУ.

Favicon

Фавикон – это тот значок, который вы видите на вкладке браузера, в закладках или на странице результатов поиска:

Как делать проверку:

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

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

Хлебные крошки

Если вы делаете технический SEO анализ сайта, вряд ли есть смысл объяснять, что такое хлебные крошки. Но если вдруг кто-то не знает, тогда вот их пример:

Проверить их очень просто – открываете несколько внутренних страниц разного типа и смотрите, есть ли они. На этом проверка закончена. Вопрос в другом – когда писать правку?

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

• уровень вложенности 4 и более – они точно нужны;
• 3 – на усмотрение владельца ресурса;
• 2 – не нужны.

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

При этом последняя часть будет не активной или вообще отсутствовать (настраивают и так, и так). В итоге по хлебным крошкам вы сможете вернуться только на главную. Смысла от них никакого. Если будет 3 уровня:

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

При большем уровне вложенности – нужно рекомендовать как крайне желательную правку.

Микроразметка

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

Микроразметка помогает сделать сниппеты более привлекательными. Например:

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

Хотите, чтобы были добавлены звездочки рейтинга, отзывы и цены – нужна микроразметка карточек товаров.

Как проверять

Можно воспользоваться сервисом проверки расширенных результатов от Google:

Проверять будем страницы:

• https://prosuver.ua/ru/contacts/ – чтобы проверить разметку контактных данных;
• https://prosuver.ua/ru/blog/seo/h1-h6/ – проверим разметку статей.

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

Результат проверки выглядит так:

Смотрим, какая разметка присутствует и есть ли ошибки. На нашем примере видим, что размечено 2 элемента и ошибок нет. Разметка сделана для статьи и строк навигации, что нам и было нужно. Значит все ок. Если ее не будет, пишем правку:

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

Заголовки H1-H6

Если не совсем понимаете, что это такое и как с ними работать – начните с изучения статьи: «Заголовки h1-h6: что это такое и как их использовать, чтобы быть лучше 90% сайтов». Там все подробно расписано.

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

Иерархия

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

Использование в навигационных элементах

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

Дубли

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

О каких дублях идет речь – только о дублировании h1 на разных страницах (дублирование h2-h6 не является проблемой). То есть, теоретически не должно быть двух страниц, имеющих одинаковые заголовки h1. Исключения, конечно, есть и нужно подходить к этому хотя бы с минимальным вниманием, а не просто копировать данные из парсера. Например:

Обе страницы имеют заголовок «Блог». Но это не проблема, потому что это разные языковые версии. А вот если у вас разные товары будут иметь одинаковые h1, вот это будет неправильно.

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

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

Если дубли h1 есть – смотрите что это за страницы. Что-то подобное моему примеру – игнорируете. Дублируются названия товаров – пишете правку, что нужно уникализировать h1 для товарных страниц. Рекомендуете добавить больше данных о товаре (цвет, размер, артикул…), чтобы сделать заголовки уникальными и более точно описывающими товар.

Мета-теги

Для новичков сперва рекомендую прочесть мои инструкции по:

• title;
• description;
• мета-тегам.

А уже потом приступать к проверке. Ситуация здесь такая же, как и с заголовками h1 в предыдущем пункте – проверять мета-теги нужно уже после оптимизации. Для проверки используем тот же парсер.

На что смотрим – пустой title или description и их дубли:

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

Также нужно просмотреть слишком короткие description и есть ли вопросы по длине title (часто бывает слишком большая длина). Если есть – также смотрим что за страницы и отправляем их на правку.

Ссылки

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

Битые ссылки

Битые ссылки – это когда у вас на сайте есть ссылки ведущие на несуществующие страницы. Какую-то страницу удалили, а ссылки на нее остались. Их тоже нужно удалить или изменить, чтобы они вели на существующие url-адреса.

Проверить их можно в том же парсере. Если такие есть – там же сморите на каких страницах находятся эти ссылки и пишете правку на их удаление.

Циклические ссылки

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

• Логотип в шапке сайта должен быть ссылкой на главную страницу. Везде, кроме самой главной страницы.
• Если в подвале есть ссылка, например, на политику конфиденциальности, то при открытии этой страницы, ссылка должна становится неактивной. Можете посмотреть как это работает на этом сайте.
• То же самое касается ссылок в меню под шапкой или в шапке.

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

Внешние ссылки

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

А сейчас посмотрим подвал/шапку сайта и страницу контактов. Часто здесь располагаются кнопки соц. сетей, а иногда и ссылки на какие-то сайты. Все они должны быть прописаны с использованием атрибута rel=«nofollow». Проверить просто – открываете исходный код, ищете нужные элементы и смотрите есть ли там rel=«nofollow». Если нет – пишете в правки, что нужно добавить nofollow в такие-то ссылки.

Дубли текста и страниц

Первые вы найдете в парсере – вкладка «Дубликаты текста». Если такие есть, тогда нужна правка для SEO-специалиста:

Дубли страниц вы найдете в Google Search Console (доступ нужно взять у заказчика) – Страницы – Страница является копией. Канонический вариант не выбран пользователем:

Искать дубли, нужно более тщательно и не только здесь. Но пока хотя бы это посмотрите.

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

Google Search Console

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

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

• Файлы Sitemap – здесь вы добавляете ссылку на свою карту сайта.
• Строки навигации – проверяете нет ли проблем с ними.
• Проблемы безопасности и нет ли на сайте фильтров.

И еще много всего. Вам в любом случае нужно пройтись по всем вкладкам и посмотреть данные. Если будут какие-то проблемы – вы это увидите. Но в первую очередь смотрите «Индексирование — Страницы». Именно там будет больше всего информации.

Как оформить технический аудит

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

• Нет никаких правил оформления.
• Писать нужно так, чтобы вас поняли.

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

А чтобы было еще проще – посмотрите на правки в статье, которые обведены в рамки. Если вы соберете их все на одном листе. А сверху напишите «ТЗ для программиста по результатам технического аудита сайта такого-то» – этого будет достаточно. Это и есть те 1-2 листа реально важных рекомендаций. И никакой воды.

Если же заказчик не знает, что вы проверяли, а что нет, тогда меняйте название на: «Технический аудит сайта такого-то». Затем перечислите то, что вы проверили, но где не было выявлено проблем и напишите, примерно так: «При проведении технического аудита было проверены: карта сайта, индексация страниц, коды ответов сервера, редиректы… по всем этим пунктам замечаний нет.»

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

Подведем итог

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