Веб-разработка для SEO: еще один почти идет на юг

Последнее обновление: 14 сентября 2018 г.

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

Необходимость

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

Многих элементов, необходимых для улучшения их SEO, просто не было. Нет возможности изменять метаданные, теги h1, теги alt/title и т. д. Большая часть этих данных генерировалась программно; а также меню и навигационная структура. Этот новый сайт также должен быть безопасным. Короче говоря, им нужен был новый безопасный веб-сайт, адаптированный для мобильных устройств, и корзина для покупок с коннектором для работы с их существующим пакетом программного обеспечения для планирования ресурсов предприятия (ERP).

Миссия

У этого клиента было 3766 ключевых слов с результатами ранжирования в первой сотне поисковой выдачи Google. Пятьсот тридцать восемь (538) ключевых слов с результатами на странице 1, со среднемесячным объемом поиска 65 790 и 43 ключевыми словами, занимающими первое место в поисковой выдаче Google, со среднемесячным объемом поиска 6 110. Моя работа заключалась в том, чтобы провести их через требования, которые новая административная система должна будет обеспечить для возможности реализации SEO в будущем. Это также включало в себя максимально возможную защиту существующих результатов рейтинга.

Выбор

В конечном итоге клиент выбрал офшорного поставщика, который мог бы обеспечить интеграцию между их существующим программным обеспечением ERP и новым, удобным для мобильных устройств, безопасным решением для корзины покупок и веб-сайтом. Не будучи знакомым с этим оффшорным поставщиком, клиент предоставил мне записанную демонстрацию продукта, чтобы подтвердить, что система администрирования предоставит то, что нам нужно для реализации SEO. После просмотра демоверсии я пришел к выводу, что у нас есть элементы, необходимые для помощи клиенту в улучшении SEO. Мы могли бы создавать собственные заголовки страниц, метаописания и теги h1. Мы могли бы обновить код Google Analytics (GA), в котором они использовали старый, устаревший код GA и не имели учетной записи Search Console. У нас был доступ к изображениям, чтобы добавить правильно отформатированный альтернативный текст/заголовок. Как мы узнали позже, и уже слишком поздно, была даже возможность применить редирект 301 прямо на каждой странице. Но это только часть истории.

Исход

Как оказалось, разработчик предоставил шаблон, корзину и интеграцию с ERP. Перед клиентом была поставлена ​​задача перенести контент (скопировать старый контент сайта и вставить на новую страницу в системе администрирования), включая существующие метаданные. Им также было поручено ввести URL-адреса старого сайта в данные новой страницы, страница за страницей. Оказывается, это было осложнено тем фактом, что клиент не мог скопировать и вставить URL-адреса старого сайта без изменений. Клиент воспринял это как стандартную рабочую процедуру и никого об этом не уведомил. Изначально мы рекомендовали разработчику создать правильный файл перенаправления 301. Сроки развертывания не позволяли клиенту позволить нам проверить правильность работы. Они только что запустили его, и тут все пошло не так.

Узнав, что перестроенный сайт запущен, мы начали вручную тестировать исходные результаты ранжирования по ключевым словам в сравнении с текущими результатами ранжирования. Просто посмотреть, как выглядит новый сайт и все ли данные перенесены. Все результаты ранжирования в поисковой выдаче Google, которые все еще были на месте, приводили к коду ответа 404, за исключением домашней страницы. Как оказалось, URL-адреса старого сайта были созданы с расширениями .html, а новые URL-адреса — нет. Система администрирования просто не позволяла вставить старый URL-адрес в предоставленное поле перенаправления 301, поэтому клиент вставил старый URL-адрес без расширения .html. Клиент предположил, что это стандартная операционная процедура.

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

Дублированный контент? Вы спросите, а тег rel= canonical был размещен? Правильно? Нет. Тег rel=canonical в удобном для поисковой системы URL-адресе с перенаправлением был установлен так, чтобы указывать на новый неудобный для поисковой системы URL-адрес, содержащий строку запроса. Изучив тег rel=canonical недружественной страницы, мы обнаружили, что этот тег ссылается на совершенно другой URL. Один, содержащий категорию, а не строку запроса. Итак, одна часть контента показывалась для трех разных URL-адресов с неправильно установленными тегами rel=canonical.

Затем мы обнаружили, что все боты были запрещены в файле robots.txt. Затем мы проверили активность в GA. Клиент по-прежнему получал посещения из всех источников, но конверсий не было. Кроме того, клиент хотел, чтобы мы активировали сканирование и индексацию, для чего требуется консоль поиска Google. Проблема здесь в том, что существующий код GA был старым, и на сайте никогда не размещался проверочный код Search Console. Это один из тех пунктов, который клиент не мог изменить по причинам, которые никогда не раскрывались.

К счастью, клиент принял нашу рекомендацию и обновил свой код GA до последней версии. Сами по себе они также добавили диспетчер тегов Google. Ой! Возможно, двойное срабатывание кода GA? С помощью Диспетчера тегов Google и обновленного кода асинхронного GA мы смогли создать новую безопасную (https или http) учетную запись Search Console для клиента, а затем обнаружили, что нет карты сайта в формате .xml, которую можно было бы отправить для запрошенного сканирования. .

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

Окончательный результат

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

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

Проблема решается за дополнительную плату клиенту от разработчика. Все существующие старые результаты ранжирования с расширением .html начали правильно перенаправляться, и в течение 14 дней результаты ранжирования были заменены новыми безопасными URL-адресами и, по большей части, очень близки к ранее существовавшим результатам ранжирования. Проблема с тегом rel=canonical была решена на онлайн-встрече с агентом по продажам веб-разработчика и сводилась к ошибке пользовательского ввода. Было несколько полей, в которые можно было ввести или выбрать данные из существующего выбора, и решение требовало сброса этих полей и очистки кеша.

Две дополнительные версии удобного и безопасного URL-адреса быстро исчезли. Что касается бота /disallow в robots.txt, после уведомления разработчик быстро решил эту проблему.

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

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

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

Что ж, эта проблема превратилась в более серьезную проблему, поскольку дополнительная карта сайта .xml сгенерировала код ответа 500, поэтому существует проблема с доступом агента Google к этой области сайта. И на сегодняшний день обе карты сайта в формате .xml генерируют 500 кодов ответов. За неделю до этого мы инициировали сканирование с помощью инструмента «Выборка, визуализация, отправка», доступного нам в Google Search Console, что, по нашему мнению, вызвало сканирование и индексацию нового сайта.

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

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

– Марк Грей, старший SEO-менеджер