Разрушение SEO-мифов, использование тега Canonical и Page Experience от Daniel Foley Carter

Всем привет! Меня зовут Андрей Симагин, я автор программы SiteAnalyzer, и в сегодняшней статье мы сделали подборку из нескольких материалов от популярного зарубежного SEO-консультанта Daniel Foley Carter на тему корректности использования тега Canonical, разрушения наиболее популярных SEO-мифов, а также изложили его мысли по работе с оптимизацией качества страниц (Page Experience).

👉 Канонические теги являются ДИРЕКТИВОЙ – Google не всегда выбирает указанный URL-адрес и поэтому может выбрать другой канонический путь вместо указанного.

«Но Дэниел, зачем тогда нужны канонические теги?»

👉 Канонические теги задумывались в качестве «последнего решения» для предотвращения таких проблем, как дублирование контента. По сути, директива была введена для того, чтобы предоставить альтернативу сайтам с серьезными структурными ограничениями (т.е. ограничениями на уровне CMS).

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

👉 Ваш сайт УСТАНАВЛИВАЕТ последовательные пути, т.е. ставит или не ставит завершающий слеш.
👉 Вы используете последовательные пути для HTTPS / не-WWW / WWW – в зависимости от конфигурации, применяемой на сайте.
👉 Ваш сайт не возвращает HTTP 200 для вариантов URL, т.е. mywebsite.com/hello и mywebsite.com/hello/ – в этом сценарии существуют 2 одинаковые страницы, но они независимы с завершающим слешем – поэтому будет применено значение из канонического тега.
👉 НЕ канонизируйте страницы пагинации на корневую страницу – если содержимое страниц различается, не канонизируйте один URL на другой.
👉 НЕ полагайтесь на канонические теги для динамических URL – если динамические параметры изменяют содержимое, то канонический тег приписывает страницы с различным содержимым друг к другу. Вместо этого используйте файл robots.txt для контроля индексации параметров (статические пути).

Зайдите в консоль поиска, перейдите в раздел «Данные индексирования страниц» («Page indexing data») и проверьте, указан ли там следующий статус:

❌ Duplicate, Google Chose Different Canonical than User (дубликат страницы, но Google выбрал другую вместо той, которую указал пользователь).

⚠ Это означает, что Google проигнорировал директиву canonical и выбрал что-то другое.

⚠ Вы также должны стараться избавиться от следующего статуса везде, где это возможно:

❌ Alternate page with proper canonical tag (дублирующиеся страницы, у которых прописан «сanonical»).

Хотя в целом это не самая серьезная проблема – это означает, что Google сканирует контент, который на самом деле не надо сканировать – контроль индексации идеально подходит для уменьшения объема сканируемых URL, которые фактически являются каноническими дочерними УРЛами.

❓ У нас несколько доменов и мы хотели бы их «склеить» (объединить) – будет ли от этого польза?

⚠ Это СИЛЬНО зависит от конкретной ситуации. Объединение множества доменов для наращивания ссылочной массы – рискованное дело, поскольку вы можете не извлечь из этого никакой выгоды – и, следовательно, впустую потеряете деньги. В целом, это можно сделать – Google, очевидно, будет выполнять переадресацию. Объединение ссылок с нескольких доменов (при наличии определенной связи между ними), как правило, выгодно – однако консолидация многочисленных доменов, скорее всего, приведет к тому, что Google начнет игнорировать дополнительную ссылочную массу (я проверял это на практике бесчисленное количество раз на протяжении многих лет).

☢ МИФ: Объединение множества доменов в один значительно усилит его.

⚠ Да, в Ahrefs возможно это сработает. Однако реальность такова: Google будет рассматривать все по своему усмотрению – объединение множества доменов не считается «нормальным поведением», поэтому совокупные преимущества консолидации нивелируется упущенной ссылочной массой (хотя бывают и редкие исключения).

❓ Мы обнаружили, что у нас много ссылок с сайтов, которые находятся в «черном списке» – не навредит ли нам это?

⚠ Прежде всего, не существует никакого «черного списка» ссылок Google. Любые сервисы, которые утверждают, что показывают домены из «черного списка», скорее всего, используют данные Semrush / Ahrefs API, в которых они ищут сайты с упавшими показателями трафика. Эти ссылки не навредят вам — они просто не принесут никакой пользы, поэтому не стоит тратить на них время и деньги.

☢ МИФ: Ссылки с сайтов из «черного списка» приведут к штрафам от Google.

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

❓ Мы собираемся запустить новый сайт – стоит ли повременить с запуском до тех пор, пока мы не начнем линкбилдинг?

⚠ Нет, создание доверия к домену – длительный процесс, поэтому вам следует запускать его при первой же возможности, а не ждать. Ссылочная масса передается независимо от того, где находится домен, если есть удерживающая страница. Уже существующий «вес» домена поможет ускорить развитие сайта после его развертывания.

☢ МИФ: Заниматься линкбилдингом нужно только после того, как вы запустите свой сайт.

⚠ Это просто миф.

Данные советы вдохновлены многочисленными аудитами, которые я проводил для «SEO Audits IO».

➡ Прекратите ухудшать «пользовательский опыт» ради метрик Core Web Vitals (CWV) – оно того не стоит.
➡ Перестаньте зацикливаться на показателях PageSpeed, если на вашем сайте много дублированного контента, проблемы с каннибализацией, присутствует малополезный / мертвый контент и есть проблемы с индексацией.
➡ Сайты с хорошим контентом (отвечающие потребностям конечных пользователей) превосходят сайты с оптимальными показателями метрик Core Web Vitals.
➡ Показатели метрик CWV проверяются в последнюю очередь после остальных факторов ранжирования, и при этом их влияние обычно незначительно.
➡ Многие сайты, которые мне довелось проверить, страдали от проблем со СКОРОСТЬЮ, выражавшихся в сдвигах макета (совокупное смещение макета (Cumulative Layout Shift, CLS) – это всегда плохо). Это раздражает, заставляет людей промахиваться мимо нужных кнопок... и, это действительно сильно бесит.
➡ Используйте валидатор CLS, чтобы убедиться, что ваши страницы нормально загружаются – например, этот: https://webvitals.dev/cls.
➡ Во многих случаях выбор технологии для создания сайта на основании скорости – это ужасная идея. Я встречал компании, которые тратили больше £1 млн. на Angular для ускорения страниц. В итоге им приходилось использовать пререндер, что приводило к плохим результатам. Я уж не говорю про кучу проблем с индексацией из-за реализации Angular.
➡ Обеспечьте соблюдение протоколов и сделайте так, чтобы они использовались последовательно – HTTPS должен быть выбран по умолчанию.
➡ Запросы без HTTPS всегда должны перенаправляться через один канал.
➡ Внутренние ссылки (абсолютные) всегда должны быть HTTPS.
➡ Убедитесь, что в SCHEMA / Markup validation используется HTTPS (включая библиотеки сторонних разработчиков).
➡ НЕ блокируйте ресурсы, используемые для рендеринга страницы – это часто приводит к предупреждениям NON MOBILE FRIENDLY. Используйте проверку URL опубликованных страниц в консоли (Google Search Console), проверьте рендеринг и блокировку ресурсов.
➡ Быстрая загрузка страниц – результат множества процессов, а не только оптимизация метрик Core Web Vitals. Для устранения проблем со скоростью используйте СПЕЦИАЛИСТОВ, а не плагины. Выберите хороший сервер с запасом производительности, удалите все ненужные плагины в CMS, уменьшите количество запросов и загружайте изображения в правильном формате (webp) с альтернативой для браузеров, которые его не поддерживают.
➡ ВСЕГДА ставьте пользовательский опыт выше скорости. Лишние полсекунды, потерянные на правильную и беспроблемную загрузку, полностью себя оправдывают. Я работал над коммерческими сайтами с миллионными бюджетами, которые зацикливались на скорости и в итоге портили показатели конверсии. Их удавалось восстановить после возвращения к более медленным, но удобным версиям страниц. Кому нужны проблемы с CLS при оформлении заказа, глюки при открытии корзины и другие сложности?
➡ SEO – ЭТО РАССТАНОВКА ПРИОРИТЕТОВ! Если страницы достаточно быстро загружаются, а их содержимое доступно, надо переходить непосредственно к контентному предложению ДО всего остального. Метрики Core Web Vitals должны находится в конце вашего списка приоритетов.

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

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

Статья написана по материалам блога Daniel Foley Carter.

Буду рад, если вы поделитесь своим опытом, комментариями и мнениями по статье.