О техническом SEO с конференции SMX Advanced

Журналист Крис Сильвер Смит побывал на конференции SMX Advanced и готов поделиться самыми свежими знаниями, полученными от инженеров SEO.

В этот раз Смит рассказал о презентациях трёх докладчиков:

• Дженни Хэлец (Jenny Halasz), президента и основателя JLH Marketing;
• Кристин Смит (Christine Smith), технического руководителя IBM Search Marketing;
• Мэйли Охай (Maile Ohye), инженера Google и Senior Developer в нём же.

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

Эффективная и выгодная реклама с сервисом от МегаФона

Широкий выбор рекламных каналов, более 100 параметров по интересам, подробная аналитика и другие возможности уже ждут в Личном кабинете. А еще кешбэк 100% за запуск рекламы в первый месяц и еще 10% — каждый месяц.

Узнать больше >>

Реклама. ПАО «МегаФон». ИНН 7812014560. ОГРН 1027809169585. ERID LjN8K1P7y.

Мэйли Охай, инженер и ведущий разработчик Google

Мэйли Охай была первым докладчиком. Её материал, посвященный тонкостям оптимизации сайтов с точки зрения Google, как обычно, оказался технически безупречен.

HTTP/2

Первой темой был HTTP/2. Мэйли начала с краткого экскурса в историю эволюции интернета, напомнив, насколько простой была самая первая версия протокола. Её авторы считали, что страницы будут загружать считанные единицы ресурсов с других источников, и поэтому загрузку можно было поставить в очередь. Сегодня среднестатистическая страница содержит более 50 ресурсов, линейная обработка которых становится тяжелым испытанием для HTTP1.x. В такой ситуации любые оптимизации пойдут на пользу, если они увеличат производительность - подгрузка облегченных изображений, создание цепочек из файлов и т.п.

Мэйли указала на основные преимущества протокола над предыдущей версией. Так, он научился загружать ресурсы параллельно, при этом понимая приоритетность и позволяя вебмастеру указывать её, и сжимать HTTP-заголовки. Что еще важнее, современные браузеры уже поддерживают HTTP/2, в частности - Google Chrome, который обещает полностью перебраться на HTTP/2 уже в следующем 2016. Всё, что требуется от сайтов, желающих перейти на последнюю версию протокола - настроить сервер на работу с ним.

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

Не исключено, что в будущем Google будет использовать наличие поддержки HTTP/2 как еще один фактор ранжирования. Похожее произошло совсем недавно с HTTPS. Но, даже если такого в планах компании нет, высокая скорость загрузки страниц сама по себе влияет на позиционирование сайта в выдаче.

HTTPS

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

(Небольшое отступление. Циничный чудак внутри меня слегка удивлен последовательностью действий Google. Сперва он продвигал скорость загрузки страницы в роль фактора ранжирования, намереваясь ускорить интернет, а затем форсировал внедрение HTTPS, который, по сути, замедляет обмен данными из-за шифрования. Теперь на первые позиции вновь выходит скорость, особенно для мобильных пользователей, где властвует алгоритм Mobile Friendly. Параллельная загрузка контента через HTTP/2 станет настоящим спасением для мобильных сайтов.

Впрочем, если смотреть на вещи трезво, увеличение времени загрузки, вызванное HTTPS, можно назвать незначительным, а параллельная загрузка ресурсов уже поддерживается всеми современными браузерами. Также, если взглянуть на принцип работы Page Speed от Google, можно увидеть, что он не зависит от скорости соединения. Намного важнее то, с какой скоростью сервер отдает информацию и как быстро страница отрисовывается в браузере. Если вы оптимизируете страницы сайта под устройство пользователя, то все мои претензии просто не имеют смысла.)

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

Рендеринг страниц

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

Если на странице подключаются ресурсы с других сайтов, убедитесь, что страница отображается раньше, чем они. Роботы кэшируют информацию, и первое, что отобразится на странице, может стать самой важной её составляющей, по мнению робота. Остальной контент, в том числе "родной", будет обозначен как средней важности, а скрытый - наименьшей. Ссылки, найденные на этапе рендеринга, анализируются как и любые другие, и также передают PageRank.

Если CSS для мобильной версии недоступен роботам Google из-за ограничений в robots.txt или других похожих проблем, страница может лишиться отметки mobile friendly и исчезнуть из мобильной выдачи. Убедитесь, что все контент-файлы страницы могут быть получены роботом.

Дженни Хэлец, президент и основатель JLH Marketing

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

Для упрощения понимания происходящего Дженни ввела две категории сигналов, воспринимаемых Google - "окончательные" и "не окончательные". Выбранные названия классов говорят сами за себя – первым Google верит практически всегда, вторым – изредка.

Окончательны сигналы

В список "окончательных" сигналов попали 301 редиректы, удаления страниц (ошибка 400), ограничения в robots.txt и использование noindex. Хэлец отметила, что редирект не всегда считается окончательным, и даже 404 "Not found" не всегда вычеркивает страницу из расписания роботов. Для удаления страниц лучше всего подошел код ошибки 410 Gone - он ясно дает поисковику понять, что страница или ресурс исчезли навсегда.

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

Можно запретить индексировать страницу при помощи robots.txt. Вес ссылок при этом сохранится, и, как только страница вернется в выдачу, она получит свой былой вес. В качестве доказательства Дженни указала на эксперимент Грэга Бозера, запретившего сканировать сайт, но всё же обнаружившего ссылки на него по некоторым запросам. Изменилось лишь представление сайта в выдаче – с него не загружались сниппеты.

Не окончательные сигналы

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

• rel=canonical: тег предназначен для указания "настоящего" адреса страницы. Альтернативные URL по-прежнему остаются в индексе из-за потенциальных несоответствий контента, неправильных редиректов или наличия неканонических  ссылок.
• rel=next/prev: эти два параметра должны помочь поисковику понять, что перед ним серия страниц. Как и в предыдущем случае, разница во внешних и внутренних ссылках может привести к индексации неверного URL как основного, либо же помешать добавить страницу в индекс вообще. Проблемы с редиректами и ошибки при делении контента на страницы также могут создать препятствия роботам
• HREF Lang & rel=alternate: эти теги предназначены для указания языка и переведенных страниц. Особенностью первого тега является поддержка двух параметров – языка и региона. Указать регион можно только после выбора языка. Ссылки, размещенные на переведенных версиях страниц, должны вести на страницы с тем же языковым кодом - английские на английские, французские - на французские.
• Непоследовательные сигналы: сюда входят сигналы, влияние которых на Google варьируется непредсказуемо. Это соответствие ссылок в Sitemap тегам страниц (в частности, указание canonical версий); соответствие основной навигации той, что указана в Sitemap; соответствие внутренних ссылок на страницу. Отдельно Дженни рекомендовала избегать использования тегаrel=canonical на страницах, которые указывают сами на себя.

Хэлец вспомнила несколько популярных ошибок, встречающихся в SEO:

• редиректы и изменения адреса станицы часто не синхронизируются с внутренними ссылками на неё;
• в ссылках опускают (или добавляют) WWW;
• неверное обращение с HTTP/HTTPS, ведущее к попаданию в индекс обеих версий;
• ошибки при обработке слэшей в конце адреса страницы;
• некорректное применение каноничных ссылок в "хлебных крошках";
• указание параметров, запрещенных в Webmaster Tools.

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

Здесь Мэйли Охай ответила, что Google не считает 301 редирект достаточно авторитетным сигналом, и в некоторых ситуациях оригинальный URL может сохранить больший вес, чем новый адрес. Такое возможно, например, при добавлении редиректа с главной страницы на страницу логина. Мэйли также добавила, что не стоит слепо доверять результатам поиска по запросу вида "site:" – они не всегда отображают реальное наличие страниц в индексе (!).

Презентация Мэйли доступна здесь .

Кристин Смит, технический руководитель IBM Search Marketing

Последней в обзоре, но не на конференции, выступила Кристин Смит с презентацией "Истории SEO-детектива", в которой разобрала три кейса, над которыми ей довелось поработать в IBM.

Кейс №1

Проблемы возникли у самостоятельного сайта IBM, на который внезапно перестал пользоваться былой популярностью. Проблемы были отмечены в ноябре 2013 года, тогда же начались проблемы с позициями в Google. За 5 месяцев трафик упал на 28%, а позиции просели так, словно сайт находился под санкциями.

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

Кристин прошла по стандартным шагам диагностики проблем, включая проверку Sitemap и его правку. Не помогло. Почти в отчаянии, Кристин связалась с техподдержкой Google Site Search. Лишь после этого выяснилось, что большинство страниц, расположенных на пострадавшем сайте, были проиндексированы незадолго до падения позиций. Из этого следовал простой вывод - страницы были признаны дубликатами страниц другого сайта IBM.

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

Виновником всего признали некорректные настройки сервера, который отдавал неверный код ошибки во время технических работ и пометил страницы недоступными. В свете этого Кристин рекомендовала не использовать 302 редирект и 500/504 ошибки на время работ, а обратиться к 503-й ошибке - Service unavailable.

Некоторые CMS уже обучены отдавать именно 503 ошибку, например - WordPress. Но множество серверов под "чистым" Apache, IHS или IIS потребуют ручной модификации rewrite-правил. Клиентам Akamai можно обратиться в компанию и попросить помощи в настройке ответа.

Кейс №2

В следующем кейсе Кристин поведала о проблеме IBM с новой страницей, на которой использовались динамические карточки, генерируемые при помощи AJAX. Страницы, ссылки на которые размещались внутри карточек, не попали в индекс Google.

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

Интересно, что Baidu и "Яндекс" вообще не выполняют скрипты страницы. Скорее всего, эти поисковики никогда не смогут увидеть контент страницы, если целенаправленно не адаптировать код.

Кейс №3

В третьем кейсе Кристин вспомнила переезд сайта Smarter Risk Journal. В ходе смены домена возникла проблема – тегом rel=canonical были отмечены лендинги, а не страницы с реальным контентом. Из-за этого Google отметил все страницы как дублированные и понизил их в выдаче. Проблему решили переносом тегов на страницы, к которым они на самом деле относились.

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

• проверка канонических URL;
• проверка robots.txt;
• проверка редиректов;
• подтверждение sitemap.

Презентацию Кристин можно увидеть здесь .

Заключение

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

Оригинал: SearchEngineLand