1. Оставляя среду разработки просматриваемой / индексируемой
2. Произвольная смена имен изображений на страницах с хорошим рейтингом
3. Удаление страниц или изменение URL-адресов страниц без их перенаправления
4. Не выполняется полный обход после перехода в среду разработки и из нее
5. Неспособность выполнить полную проверку функции на всем
6. Не удалось перенастроить WordPress и плагины после миграции на работающий сервер
7. Пренебрегая вниманием к деталям

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

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

Никто не хочет этого.

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

Оставляя среду разработки просматриваемой / индексируемой

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

Я склонен попадать в последнюю категорию.

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

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

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

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

Произвольная смена имен изображений на страницах с хорошим рейтингом

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

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

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

Удаление страниц или изменение URL-адресов страниц без их перенаправления

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

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

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

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

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

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

Если вы не можете увидеть файл .htaccess на своем сервере, вам может потребоваться настроить параметры вашей FTP-программы для просмотра скрытых файлов.

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

Не выполняется полный обход после перехода в среду разработки и из нее

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

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

domain.com/services/

После миграции в среду разработки это может быть:

devdomain.com/client123/services/

Пока все хорошо и хорошо, правда?

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

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

К счастью, решение простое. Инструмент, подобный Screaming Frog, который запускается с вашего рабочего стола, или облачный инструмент, такой как SEMrush, можно использовать для сканирования каждой ссылки на вашем сайте. Это включает в себя текстовые ссылки, видимые в интерфейсе, а также все ссылки на файлы изображений, JavaScript и CSS, которые спрятаны в HTML веб-сайта.

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

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

Неспособность выполнить полную проверку функции на всем

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

Это включает:

• Контактные формы.
• Функциональность электронной коммерции.
• Поисковые возможности.
• Интерактивные инструменты.
• Мультимедийные плееры.
• Аналитика.
• Проверка Консоли поиска Google / Инструменты для веб-мастеров Bing.
• Отслеживание пикселей.
• Динамическая реклама.

Не удалось перенастроить WordPress и плагины после миграции на работающий сервер

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

Без этого легко. Это также разрушительно. На самом деле, это ошибка, которую я сделал несколько лет назад.

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

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

Это включает в себя плагины для:

• SEO.
• Перенаправление.
• Sitemaps.
• Схема.
• Кэширование.

Пренебрегая вниманием к деталям

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

Мнения, выраженные в этой статье, принадлежат автору гостя и не обязательно относятся к Search Engine Land. Штатные авторы перечислены Вот ,

Об авторе

Похожие

Комментарии