Полный SEO контрольный список для веб-разработчиков

1. Правильно ли установлены мои инструменты Google для веб-мастеров? Установлена ​​ли Google Analytics...
2. Контрольный список № 1: Правильно ли установлена ​​моя программа отслеживания трафика?
3. Посмотрите на это: Mobile First Development
4. Контрольный список №2: Ваш сайт удобен для мобильных устройств?
5. Элемент контрольного списка № 3: структуры мобильных URL-адресов, приводящие к дублированию контента
6. Посмотрите на это: Schema.org Структурированные данные
7. Контрольный список № 4: Правильно ли закодированы мои структурированные данные?
8. Посмотрите на это: проверьте ваш файл Robots.txt
9. Элемент контрольного списка № 5: Имеет ли мой файл Robots.Txt директиву «Запретить из корневого каталога»?
10. Посмотрите на это: промежуточная проверка домена сайта
11. Элемент контрольного списка № 6: Содержит ли мой сайт экземпляры промежуточных поддоменов сайта?
12. Посмотрите на это: ошибки HTML
13. Элемент контрольного списка № 7: Содержит ли мой сайт основные случаи ошибок кодирования?
14. Элемент контрольного списка № 8. Содержит ли мой сайт эффективный макет кода?
15. Посмотрите на это: проблемы с изображением
16. Контрольный список №9: образы вызывают ненужные узкие места?
17. Различные платформы разработки: являются ли изображения чрезмерно большими, когда они не должны быть?
18. Посмотрите на это: поисковые плагины, другие плагины
19. Элемент контрольного списка № 10: Какие-нибудь плагины Rogue вызывают серьезные проблемы с SEO?
20. Посмотрите на это: скорость сайта и конфигурации сервера
21. Элемент контрольного списка № 11: Использует ли ваш сервер сжатие GZip?
22. Элемент контрольного списка № 12: время загрузки сервера до первого байта
23. Заключительные мысли о расставании

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

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

Правильно ли установлены мои инструменты Google для веб-мастеров? Установлена ​​ли Google Analytics (или инструмент выбора статистики)?

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

Контрольный список № 1: Правильно ли установлена ​​моя программа отслеживания трафика?

Если ваша программа отслеживания не установлена ​​должным образом, возможно, она выдаст ошибочные, неверные данные или, что еще хуже, дублирующиеся данные, показывающие увеличение, когда их даже может не быть. В самом простом случае убедитесь, что теги программы отслеживания (при необходимости) устанавливаются только один раз на странице. Многократные установки и ошибочные установки могут стать главными головными болями позже. Google рекомендует использовать Google Tag Manager для более сложных аналитических установок.

Посмотрите на это: Mobile First Development

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

Контрольный список №2: Ваш сайт удобен для мобильных устройств?

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

1. Придерживается ли сайт стандартных методов разработки с использованием адаптивной таблицы стилей CSS с медиа-запросами? Или же…
2. Использует ли сайт отдельный мобильный поддомен (m.domain.com)? Хотя нет ничего плохого в использовании мобильного субдомена, это может усложнить SEO.

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

Элемент контрольного списка № 3: структуры мобильных URL-адресов, приводящие к дублированию контента

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

Дублированный контент может возникнуть в результате использования нескольких URL-адресов для отображения одного и того же контента. При создании мобильного сайта с использованием мобильного поддомена рекомендуется использовать тег rel = canonical для отображения сайта рабочего стола в качестве исходного источника контента. Это может помочь предотвратить проблемы с дублированием контента. Обратите внимание, что Руководство разработчика Google Также рекомендуем сделать это.

Кроме того, убедитесь, что структуры URL во время разработки не выходят из-под контроля, особенно при настройке сайта для https: // (безопасный протокол передачи гипертекста). Это типичный протокол разработки для получения безопасных сертификатов для сайтов, которые используют https: //, но будьте осторожны. Если вы не приобретете правильный безопасный сертификат, вы можете создать проблемы с сканированием из-за программ 404. Это примерно так: если страница контента находится на https: // www и https: //, это просто приводит к проблемам сканирования и дублирования контента, потому что Google легко запутывается из-за нескольких URL-адресов, показывающих один и тот же контент.

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

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

Посмотрите на это: Schema.org Структурированные данные

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

Контрольный список № 4: Правильно ли закодированы мои структурированные данные?

Создание процесса, в котором вы вручную проверяете структурированные данные Schema.org с помощью инструмента проверки Google Schema.org, - это хороший процесс, который поможет вам стать более успешным программистом. Без этого вы будете слепы и будете в замешательстве от Google, если эти данные не будут правильно выполнены. Хотя наиболее распространенные ошибки выявляются с помощью Инструмент тестирования структурированных данных Google Есть и другие незначительные ошибки, которые могут не произойти. Эти другие ошибки имеют решающее значение для исправления, поэтому давайте рассмотрим, что может произойти, если вы этого не сделаете.

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

<div itemscope itemtype = ”brand”> <span name = ”organization”> Название компании, защищенной авторским правом, все права защищены </ span> </ div>

<div itemscope itemtype = ”brand”> Авторские права <span name = ”organization”> Название компании </ span>, все права защищены </ div>

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

Это один из примеров ошибок контекстного кодирования, которые могут возникнуть при кодировании микроданных Schema.org. Ошибки такого типа не будут отображаться ни в одном автоматическом инструменте, например, в инструментах Google для веб-мастеров, поэтому для поиска этих ошибок необходимо выполнить ручную проверку. Если используется первый пример кодирования, Google покажет расширенный фрагмент как «Название компании, авторские права защищены. Все права защищены» вместо отображения расширенного фрагмента как «Название компании», что и должно произойти.

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

Посмотрите на это: проверьте ваш файл Robots.txt

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

Disallow: /

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

Теперь есть большая разница между «Disallow:» и «Disallow: /». Для тех, кто не занимается SEO, эти директивы могут показаться запутанными.

• Disallow: (без косой черты) означает, что все пауки поисковых систем и пользовательские агенты могут сканировать сайт без проблем из корня сайта вниз.
• Disallow: / (с косой чертой) означает, что все, начиная с корня сайта и далее, будет полностью заблокировано от доступа индексации поисковой системой.

Элемент контрольного списка № 5: Имеет ли мой файл Robots.Txt директиву «Запретить из корневого каталога»?

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

Посмотрите на это: промежуточная проверка домена сайта

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

Элемент контрольного списка № 6: Содержит ли мой сайт экземпляры промежуточных поддоменов сайта?

С помощью эффективных методов поиска и замены можно быстро найти и заменить любые экземпляры субдомена промежуточного сайта. Например, в вашей любимой программе разработки, используя Ctrl + H на компьютере с Windows (или cmd + H на Mac), вы можете легко использовать find и replace для поиска всех случаев вхождения субдомена промежуточного сайта (для ради нашего примера давайте используем «stage. domain.com»). Когда сайт переключается в режиме реального времени, domain.com будет отображаться полностью, а не stage.domain.com. Но, если процесс проверки не реализован, сайт может начать работать с URL-адресом stage.domain.com, на который ссылаются везде.

Обратите внимание: этот процесс проверки, скорее всего, не понадобится, если во время разработки используется относительный URL, а не абсолютные URL. Для тех, кто не знаком с этим, относительные URL-адреса отбрасывают все перед первой подпапкой в ​​структуре URL-адреса, оставляя ее похожей на это: «папка 1 / папка 2 / page.html». Абсолютный URL включает в себя domain.com в начале структуры URL, поэтому он выглядит следующим образом: «domain.com/folder 1 / folder 2 / page.html». Это в случае абсолютных структур URL, где эта проверка необходима. В зависимости от конфигурации вашего сайта вам может даже не понадобиться реализовывать этот шаг.

Посмотрите на это: ошибки HTML

Распространенные ошибки HTML часто могут привести к плохому отображению сайта на различных платформах, что, в свою очередь, может вызвать проблемы с пользовательским интерфейсом и скоростью сайта. Это может вызвать проблемы с производительностью сайта с точки зрения рейтинга. Хотя это и не является прямым влиянием на ранжирование, оно может быть косвенным влиянием на ранжирование, например, когда не используется действительный код W3C. W3C-валидность не требуется для ранжирования сайтов, но это может привести к косвенному увеличению ранжирования, поскольку валидность W3C может помочь снизить скорость сайта за счет более оптимизированных макетов и методов кодирования. Более совершенные методы кодирования также могут помочь Google лучше понять ваш сайт.

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

Стоит также отметить, что при рассмотрении проблем HTML существуют две точки зрения. Одна школа мысли считает, что правильное кодирование не является обязательным, что сайт все равно будет работать и хорошо работать в Google. Другая школа считает, что правильное кодирование может привести к повышению производительности, включая повышение производительности в результатах поиска. Кто прав? Это мнение автора, что правильный ответ - всегда проверять вашу кодировку.

Как зарождающийся разработчик перешел на SEO, я всегда руководствовался полной проверкой и проверкой W3C на своих сайтах, КОГДА у меня есть полный и полный контроль над ними. Всегда ли возможно достичь такого типа кодирования нирваны? Я думаю так. Существуют ситуации, когда такой идеал кодирования невозможен, поэтому необходимо оценить ситуацию самостоятельно, так как не все, что здесь обсуждается, всегда будет применяться.

Элемент контрольного списка № 7: Содержит ли мой сайт основные случаи ошибок кодирования?

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

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

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

Элемент контрольного списка № 8. Содержит ли мой сайт эффективный макет кода?

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

С точки зрения клиента это также может повлиять на время загрузки. Рассматривая кодирование на стороне клиента, давайте немного путешествуем во времени. Еще в давние времена 1998 года, нередко находили макеты кода с 2400 строками и 2400 столбцами в таблицах без CSS. Здесь, в 2017 году, также нередко можно найти макеты раздутого кода с 50 строками и 50 столбцами, созданными полностью во вложенных DIV, где количество строк и столбцов неуместно и ничего не вносит в общий макет.

Конечно, я преувеличиваю по количеству. Немного подумав о макете, можно сжать некоторые чрезмерно раздутые макеты до трех DIV (и, возможно, одного или двух вложенных DIV): заголовок, содержимое и нижний колонтитул. Это относится к клиентской части. С точки зрения серверной части, компоновки кода всего, от PHP до JavaScript, CSS и HTML, эффективная практика разработки должна учитывать минимизацию кода, а также лучшие макеты кодирования.

Еще одна проблема: метатеги также должны кодироваться в соответствии с DOCTYPE. Если валидатор W3C выдает ошибки из-за метатегов, это, скорее всего, вызвано тем, что в DOCTYPE используются самозакрывающиеся метатеги, которые их не предусматривают. Например: (<meta name = «description» content = «» />) в отличие от <meta name = «description» content = «»>). Первый является экземпляром самозакрывающегося метатега, который может потребоваться в документах XHTML. В стандартном HTML 5 его не требуется использовать. Убедитесь, что вы знаете правила и как их реализовать при использовании разных DOCTYPE. В противном случае эти ошибки могут вызвать проблемы.

Посмотрите на это: проблемы с изображением

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

Хорошо, давайте снова путешествуем во времени. В старые времена 1998 года было обычным делом следить за тем, чтобы размер страниц никогда не превышал 35 кБ. В соответствии с HTTP Архив большинство веб-страниц теперь не превышают 14 КБ для файлов HTML (не включая изображения). Большинство веб-страниц по состоянию на 15.12.2016 не превышают 648 КБ, что включает в себя все потенциальные элементы (например, скрипты, шрифты, видео, изображения и т. Д.). Каков наилучший размер страницы для таргетинга при разработке сайта? Наименьший возможный размер, учитывая то, для чего вы разрабатываете. Любое улучшение скорости сайта может повысить общую эффективность вашего сайта.

Контрольный список №9: образы вызывают ненужные узкие места?

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

Различные платформы разработки: являются ли изображения чрезмерно большими, когда они не должны быть?

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

Это может привести к тому, что изображение размером 20 x 20 на WordPress будет размером 2 МБ, если вы не будете осторожны. Чтобы этого не происходило, всегда открывайте изображение в Photoshop (или в любой используемой вами программе сжатия изображений), чтобы изменить его размер и правильно сжать, используя сжатие без потерь. Делая это и внимательно следя за окончательным размером загрузки изображений в WordPress, вы убедитесь, что непреднамеренное увеличение размера файла не окажет негативного влияния на скорость вашего сайта.

Посмотрите на это: поисковые плагины, другие плагины

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

Элемент контрольного списка № 10: Какие-нибудь плагины Rogue вызывают серьезные проблемы с SEO?

Другие плагины-мошенники могут вызывать серьезные проблемы с SEO, особенно когда они автоматически вставляют такие ссылки, как ссылки, в нижние колонтитулы ваших страниц (ссылки на нижний колонтитул всего сайта для ссылок ради Руководство Google для веб-мастеров : «Широко распространенные ссылки в нижних колонтитулах или шаблонах различных сайтов») и другие вопросы.

Посмотрите на это: скорость сайта и конфигурации сервера

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

Сначала начните с проверки скорости вашего сайта с помощью инструмента Google Page Speed ​​Testing. Они переместили большую часть своей скорости страницы и другие идеи в свои Мобильный тестовый инструмент , Кроме того, я рекомендую также использовать инструмент тестирования сайта webpagetest.org ,

Элемент контрольного списка № 11: Использует ли ваш сервер сжатие GZip?

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

Элемент контрольного списка № 12: время загрузки сервера до первого байта

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

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

Заключительные мысли о расставании

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

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

Популярное изображение: Rawpixel / DepositPhotos.com

Фото № 1: tatsianama / DepositPhotos.com

Фото в посте № 2: spaxiax / DepositPhotos.com

Фото № 3: iinspiration / DepositPhotos.com

Фото № 4: Скриншот [Брайан Харниш] [из презентации Майкла Кинга Технический Ренессанс SEO ]. Снято в феврале 2017 года.

Фото № 5: ibphoto / DepositPhotos.com

Фото № 6: Wavebreakmedia / DepositPhotos.com

Похожие

Комментарии