Зачем и как решать техническую часть SEO перед созданием ссылок

Хотите получить полные выгоды от ваших усилий по созданию ссылок? Сначала займитесь технической частью SEO. Вот что вы можете сделать перед началом кампании по созданию внешних ссылок.

Зачем и как решать техническую часть SEO перед созданием ссылок

автор: Brian Harnish

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

Лучшие результаты достигаются, когда вы учитываете все аспекты SEO вашего веб-сайта:

  • Техническое SEO.
  • Контент.
  • Ссылки.

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

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

Ваши основные цели с техническим SEO – убедиться, что ваш сайт:

  • Легко индексируется поисковыми системами.
  • Имеет высокую кросс-платформенную совместимость.
  • Быстро загружается как на компьютере, так и на мобильных устройствах.
  • Не имеет проблем с неправильным кодом Google Analytics.

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

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

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

Если Ваш сайт разработан на платформе SHOP'N'SEO, можете смело пропускать эту главу. Все проблемы, описанные здесь, на платформе невозможны. Платформа изначально создавалась с прицелом на безупречное техническое СЕО.

Если ваш сайт на другом движке – читайте!

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

Безопасное HTTPS-соеинение

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

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

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

Если у вас нет полного универсального сертификата и у вас есть параметры URL на поддомене, которые не охватываются вашим сертификатом, вы не сможете перенаправлять эти URL-адреса на https://.

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

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

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

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

У вас не должно быть 10-15 или более перенаправлений на каждый URL на вашем сайте. Если так происходит, что-то серьезно не так.

Пример правильных перенаправлений

Контент на HTTPS- и HTTP-URL не должен загружаться одновременно

Правильная реализация предполагает, что один из них должен перенаправлять на другой, а не оба.

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

Если вы вводите URL-адреса вашего сайта в браузер, попробуйте и протестируйте https:// и http:// отдельно.

Если оба URL загружаются, вы отображаете две версии вашего контента, и дублированные URL-адреса могут привести к проблемам с дублированием контента.

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

Как создавать перенаправления в htaccess на серверах Apache

Вы можете выполнять глобальные перенаправления на уровне сервера в файле .htaccess на серверах Apache.

Чтобы заставить весь веб-трафик использовать HTTPS, вам нужно использовать следующий код. Убедитесь, что добавляете его выше любого кода с аналогичным префиксом (RewriteEngine On, RewriteCond и т. д.)

RewriteEngine On
RewriteCond %{HTTPS} !on
RewriteCond %{REQUEST_URI} !^/[0-9]+\..+\.cpaneldcv$
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Если вы хотите перенаправить только указанный домен, вам следует использовать следующие строки кода в вашем файле htaccess:

RewriteCond %{REQUEST_URI} !^/[0-9]+\..+\.cpaneldcv$
RewriteCond %{REQUEST_URI} !^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Comodo\ DCV)?$
RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.com [NC]
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

Не забудьте изменить любые URL-адреса в приведенных выше примерах на правильные на вашем домене.

ПРЕДУПРЕЖДЕНИЕ: если у вас нет уверенности в своих способностях вносить правильные изменения на уровне сервера, убедитесь, что ваша компания по обслуживанию сервера/специалист по ИТ проведет эти исправления для вас.

С такими видами перенаправлений вы можете серьезно что-то испортить, если не знаете точно, что делаете.

Все ссылки на сайте должны быть изменены с "HTTP://" на "HTTPS://"

Даже если вы выполняете перенаправления, описанные выше, вы должны выполнить этот шаг.

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

Если вы используете последние, это менее важно, и, вероятно, вам не нужно уделять этому много внимания.

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

Потому что Google может и будет индексировать все эти ссылки, и это может привести к проблемам с дублированием контента.

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

Одна версия.

Одна серия URL-адресов.

Одно содержание.

Нет путаницы.

Примеры ссылок, которые следует изменить с http:// на https://
Отсутствие 404-х ошибок при переходе от HTTP:// к HTTPS://

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

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

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

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

Хотя Джон Мюллер из Google утверждает, что бюджет индексации не имеет значения, кроме как для чрезвычайно крупных сайтов:

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

Джон написал: "По моему мнению, бюджет индексации переоценен". "Большинству сайтов не нужно беспокоиться об этом. Это интересная тема, и если вы индексируете веб или управляете сайтом с многомиллиардным URL, это важно, но не для среднего владельца сайта", – добавил он."

Отличная статья от Евгения Хутарнюка, руководителя SEO в SEO PowerSuite, отлично формулирует это:

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

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

Как исправить любые 404-е ошибки, которые могут возникнуть

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

Структура URL не должна быть излишне сложной

Структура URL-адресов – важное соображение при подготовке вашего сайта к техническому SEO.

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

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

Более удобочитаемые URL-адреса

Когда вы создаете URL-адреса, вероятно, вы думаете о том, куда идет контент, и затем вы автоматически создаете URL-адреса.

Однако это может повредить.

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

Например:

  • /content/date/time/keyword
  • /content/date/time/string-of-numbers
  • /content/category/date/time/
  • /content/category/date/time/parameters/

Ни один из этих форматов, с которыми вы сталкиваетесь, не очень удобочитаем, верно?

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

Это еще важнее сегодня также по соображениям доступности.

Чем более читаемыми являются ваши URL-адреса, тем лучше:

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

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

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

Дублирование URL-адресов

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

Когда речь идет о проблемах с дублированием контента, основные причины следующие:

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

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

Избегайте использования динамических параметров

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

У Джес Шольц есть удивительная статья на Search Engine Journal, посвященная основам динамических параметров и обработке URL-адресов и как это может повлиять на SEO. Шольц объясняет, что параметры используются для следующих целей:

  • Отслеживание.
  • Переупорядочивание.
  • Фильтрация.
  • Идентификация.
  • Пагинация.
  • Поиск.
  • Перевод.

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

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

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

Короткие URL-адреса лучше, чем длинные

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

Джон Мюллер из Google обсудил это:

"Что определенно играет роль здесь, из двух URL с одинаковым содержимым мы выберем один для отображения в результатах поиска. И это будет короткий URL. Это не означает, что это фактор ранжирования. Это значит, что из двух URL, одного короткого, а второго длинного, которые показывают одно и то же содержимое, мы выберем короткий.

Здесь есть много исключений, различных факторов, но если все остальное равно – у вас есть короткий и длинный, мы выбираем короткий."

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

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

Примеры избыточно сложных URL-адресов

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

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

Плохо закодированный дизайн сайта

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

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

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

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

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

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

Страницы долго загружаются

С июля 2018 года Google внедрил скорость загрузки страниц как фактор ранжирования в свой мобильный алгоритм для всех пользователей.

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

Но и для всех ваших пользователей тоже.

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

Медленно загружающиеся изображения

Если на вашем сайте много изображений размером около 1 МБ (1 мегабайт) и больше, у вас есть проблема.

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

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

Обычно рекомендуется, что для большинства сайтов изображения должны иметь размер не более 35–50 Кб на изображение. Это зависит от разрешения и плотности пикселей (включая то, учитываете ли вы более высокие плотности пикселей на iPhone и других устройствах).

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

Эффективные методы программирования

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

Рекомендации веб-мастера Google предлагают использовать действительное кодирование W3C для создания кода для вашего сайта.

Используйте действительный HTML.
Но Джон Мюллер (и даже Мэтт Каттс) ранее упоминали, что не столь важно фокусироваться на действительном кодировании W3C по причинам ранжирования. Но вот ключевое слово – фокусировка на этом с точки зрения ранжирования.

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

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

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

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

Но в конечном итоге, что лучше и почему?

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

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

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

Например, если ваш синтаксис недействителен в вашем заголовке или вы неправильно закрываете теги, валидатор кода W3C выявит эти ошибки.

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

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

Это может быть катастрофой для совместимости с разными платформами.

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

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

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

Вот почему важно приступить к техническому SEO перед созданием ссылок

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

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

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

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

Заключение

Сроки: Месяц 1, 2, 3 и каждый квартал

Обнаружение результатов: 1-4 месяца после внедрения

Необходимые инструменты:

  • Screaming Frog
  • DeepCrawl
  • Ahrefs (или Moz)
  • Google Search Console
  • Google Analytics

Преимущества создания ссылок с использованием технического SEO:

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