Краткий обзор по СЕО

Автор: Don Berto | 27 марта 2016 г.
Что же, если у вас есть собственный сайт или вы обслуживаете чей-то сайт, то вы должны знать насколько велико значение понятия СЕО. Данный обзор вкратце раскрывает точный список всех технических особенностей поисковой оптимизации. Вот, что думает об этом Матиас Джениар!

Использование доменного имени: с и без WWW-поддомена

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

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

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !www.вашсайт.ru$ [NC]
RewriteRule ^(.*)$ http://www.вашсайт.ru/$1 [L,R=301]

Важно придерживаться следующей логики: если доменное имя (%{HTTP_HOST}) не соответствует адресу www.вашсайт.ru, то его следует перенаправить  его 301-редиректом на www.вашсайт.ru. Отлично, в итоге мы получаем то, что при обращении по другому адресу  моего сайта, отличающегося от www.вашсайт.ru будет перенаправлен именно на него.

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

server {
...
if ($http_host != 'www.вашсайт.com') {
rewrite ^(.*)$ http://www.вашсайт.com$1;
}
}

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

server {
listen 80;
server_name вашсайт.com alternativedomain.com;
# Force rewrite for everything that reaches this vhost to www.вашсайт.com
return 301 http://www.вашсайт.com$uri;
}
server {
listen 80;
server_name www.вашсайт.com;
# The rest of your vhost logic goes here
}

Вот, ну, а второй способ решения исходной задачи, это создать 2 виртуальных хоста (vhost): второй из них должен содержать конфигурацию для действующего. В идеале должен быть только один компонент server_name, содержащий окончательное доменное имя вашего сайта. Первый серверный блок содержит набор серверных имен, представляющих из себя алиасы или псевдонимы к основному сайту, но при этом их не следует использовать. Любой сайт, ссылающийся на эти доменные имена, будет обращаться к секции перенаправления и перебрасывать на новое доменное имя, которое должно использоваться и входить в состав второго виртуального хоста (vhost). Для всего этого требуется побольше времени на работу с конфигурационным файлом, но оно более эффективно для работы с Nginx.

Предпочтение отдается HTTPs, нежели HTTP

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

Google предпочитает HTTPs, нежели HTTPS (даже если на это предпочтение приходится всего лишь 0,0001%), так что если у вас есть такая возможность активировать HTTPs-протокол, сделайте это! С момента подъема шифрования соединения, некоторые хостинг-провайдеры даже начали предлагать использовать бесплатные SSL-сертификаты для всех своих клиентов. Такие бесплатные предложения не стоит упускать. Но будьте бдительны, интеграция HTTPs бывает и не безопасной.

Итог правильной реализации дает зеленый замочек перед названием доменного имени в адресной строке, но малейшая ошибка (например, смешанный тип контента, когда вы включаете HTTP ресурсы в  HTTPs сайт) могут испортить все. Если вы все же активировали HTTPs-соединение у сайта, убедитесь, что все HTTP-соединения точно перенаправляют на HTTPs. Если вы этого не сделаете, поисковые системы могут начать индексировать 2 версии вашего сайта и относиться к ним по-разному.

Если вы используете Nginx в качестве обратного прокси-сервера за Apache, внести в файлик .htaccess следующий код:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

В самом же Nginx вы можете использовать различные варианты реврайта, как это написано было выше в статье. Виртуальный хост, отвечающий по 80 порту должен перебрасывать все на 443 порт (HTTPs).

server {
listen 80;
server_name вашсайт.com www.вашсайт.com;
# Rewrite all to HTTPs
return 301 https://www.вашсайт.com$uri;
}
server {
listen 443 ssl;
server_name www.вашсайт.com;
# Your vhost logic goes here
}

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

Page speed: оптимизация, как ответная реакция

Результатом должен быть четкий план действий: какие CSS или JavaScripts оптимизировать, куда добавлять кеш-заголовки и прочее. Если ваш ресурс крутится на Apache, то вы можете добавить нижеприведенный код в файл .htaccess, чтобы статичная часть вашего контента (такое как CSS, JavaScripts, картинки и др) кешировалось сроком до 2 недель:

<IfModule mod_headers.c>
<filesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|swf|css)$">
Header set Cache-Control "max-age=1209600, public"
</filesMatch>
</IfModule>

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

В случае, когда веб-ресурс поддерживается на Nginx, рекомендуется использовать что-то подобное:

server {
..
location ~ \.(jpg|jpeg|png|gif|ico|css|js)$ {
expires 14d;
}
}

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

Присваивайте правильные мета-теги для заголовка (title) и описания (description)

Помните о необходимости присвоения корректных МЕТА-тегов для заголовка и описания - это имеет решающее значение для вашего сайта.

<HTML>
<title> Mailing List Archive - MARC</title>
<meta name="description" content="A public mailing list archive for open source projects.">
...

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

Семантическая разметка страницы: h1. h2, h3 - h6

Используйте HTML элементы в своих интересах: H1-заголовок для должен быть самым важным заголовком, H2-заголовок - следующий по рангу заголовок, H3 - следующий и т.д. Google анализирует ваш контент и использует эти теги в качестве ориентиров.

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

Устраните дублирование содержимого

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

http://yoursite.tld/page/?search=keyword&page=5&from=homepage
http://yoursite.tld/page/?page=5&search=keyword&from=homepage
http://yoursite.tld/search/keyword/?page=5
...

Все эти ссылки могут указывать на один и тот же контент: управление ссылками, его переменными можно выполнять с помощью .htaccess, иначе для Google это может быть оценено как 3 уникальные ссылки, ведущие на один и тот же материал. Бывает довольно сложно все это исправить и более того отследить, но следует держать это в своей голове при разработке любого нового сайта. В случае, когда необходим показ одного и того же содержимого с разных ссылок, Вам следует:

  • Присвоить корректные Мета-теги для предотвращения индексации: <meta name="robots" content="noindex,follow"/>
  • Присвоить 301-редирект к конечной ссылке

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

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

Чистые ссылки (URLs)

Если вы помните еще в начале 2000-ых ссылки выглядели так:

site.tld/page.php?page_id=512
site.tld/profile.php?id=12
site.tld/forumpost.php?thread=66

Подход отображения такого рода ссылок, как вывод ID-шников материала в базе данных, постепенно использовался все реже и реже. В наши дни ссылки выглядят так:

site.tld/9-ways-to-make-money-online
site.tld/profile/mattias-geniar
site.tld/forum/thread/how-do-i-undelete-a-file-in-linux
...

У данных ссылок есть и несколько общих черт:

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

Если вы все еще используете ссылки, как в самом первом варианте, подумайте о применении чистых ссылок с соблюдением структурной иерархии для всех ваших страниц, как во 2-ом примере. Что же касается споров о наличии в конце ссылки на страницу знака слеш «/», то я не считаю, что он имеет какое-либо значение с точки зрения SEO, поэтому какой стиль отображения использовать - выбирать вам. 

Адаптивные макеты

Наличие адаптивного дизайна дает более высокий балл для мобильного поиска, чем неадаптивный дизайн. Если ваш текущий сайт до сих пор не поддерживает адаптивность, подумайте о том, чтобы сделать это одним из приоритетных шагов в ближайшем будущем при первой возможности редизайна. Я обычно полагаюсь на Twitter Bootstrap - по сути CSS-фреймворк с поддержкой адаптивности из коробки. Одним из ключевых технических аспектов адаптивного дизайна является наличие правильного мета-тега в заголовке страницы:

<meta name="viewport" content="width=device-width, initial-scale=1.0">

Благодаря Twitter Bootstrap добиться адаптивности стало очень просто и более не занимает много времени. Как не-разработчик мне понадобилось больше времени, чтобы привыкнуть к сетке Bootstrap и приходилось тестировать макеты на многих разрешениях, но в конце концов усилия того стоили.

Robots.txt

Поисковые системы ищут robots.txt в корневом каталоге вашего веб-сайта для получения инструкций о том, как сканировать ваш сайт. При следующем раскладе в файле robots.txt индексируется все и ничего не блокируется:

User-agent: *
Disallow:

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

User-agent: *
Disallow: /search
Allow: /search/about
Disallow: /sdch
Disallow: /groups
...

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

Sitemap.xml

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

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

Google's Webmaster Tools

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

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

Twitter Cards

Что Twitter должен делать с СЕО? Ну, больше, чем вы думаете. Наличие ссылок, которые попали в социальные сети, увеличивает шанс быть опубликованым на нескольких веб-сайтах, тем самым увеличивая естественный охват и показатель PageRank. Реализация Twitter Cards не требует больших усилий, но они могут быть и существенными. По-существу вам необходимо добавить набор дополнительных заголовков (тегов), которые Twitter сможет определять каждый раз, как расшаренную в сети. Выглядеть это может так:

<meta name="twitter:card" content="summary" />
<meta name="twitter:title" content="[openssl-announce] OpenSSL Security Advisory" />
<meta name="twitter:description" content="Public mailing list archive for [openssl-announce] OpenSSL Security Advisory" />
<meta name="twitter:image" content="https://marc.ttias.be/assets/social_logo.png" />
<meta name="twitter:creator" content="@mattiasgeniar" />
<meta name="twitter:site" content="@mattiasgeniar" />

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

Facebook's Open Graph

По той же причине, что и Twitter Cards, вам следует реализовать у себя на сайте и Facebook's Open Graph. Помимо прочего, Facebook предлагает вам URL-отладчик проблем, чтобы помочь диагностировать проблемы со своими заголовками. Для примера, заголовки с внедрением Facebook's Open Graph выглядят так:

<meta property="og:url" content="https://marc.ttias.be/openssl-announce/2016-03/msg00002.php" />
<meta property="og:type" content="article" />
<meta property="og:title" content="[openssl-announce] OpenSSL Security Advisory" />
<meta property="og:description" content="Public mailing list archive for [openssl-announce] OpenSSL Security Advisory." />
<meta property="og:site_name" content="Mailing List Archive (MARC)" />
<meta property="og:image"  content="https://marc.ttias.be/assets/social_logo.png" />

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

HTML мета-теги для индексации

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

<meta name="robots" content="index, follow">

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

<meta name="robots" content="noindex, follow">

Индексация 404-страниц на вашем сайте

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

HTTP 200 OK

Если вы сканируете свой сайт, то в идеале вы должны получать только HTTP/200 ответы.  HTTP/200 ответ ничто иное, как сообщение "ОК, содержимое доступно». Все иное может означать, что содержимое отсутствует (404-ответ), битое (503-ответ) или перенаправлено (301/302-ответы). Но в идеале, вы никогда не должны ссылаться на эти ответы, а в конечном счете должны обращаться к доступной странице по назначению.

Геолокация вашего IP-адреса

Если ваш сайт предназначен для Бельгии, убедитесь в том, что он размещен в Бельгии. В данных WHOIS после IP-адреса можно указывать местоположение. Если же ваш ресурс нацелен на несколько регионов, рассмотрите вариант технического расширения:

  • CDN от CloudFlare может помочь вам разместить ваш сайт по всему земному шару.
  • Настройте собственную проксю на нескольких языках и перенаправьте сайт по доменным зонам в соответствии со странами отображения.

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

Обслуживание сайта - HTTP 503 ошибка

Каждый раз, когда вам необходимо выключить ваш сайт на продолжительный период в связи с техническим обслуживанием, используйте в качестве ответа от сайта заголовок с 503-ошибкой на всех страницах. Заголовок HTTP 503 означает «сервис недоступен» и именно это случается во время технического обслуживания. Google не будет индексировать страницу с 503 заголовком, а рассмотрит сайт, как «временно не работает» и попробует повторить попытку позже.

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

RewriteEngine On
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^.*$ /maintenance.html [R=503,L]
ErrorDocument 503 /maintenance.html

# Make sure no one caches this page
Header Set Cache-Control "max-age=0, no-store"

В итоге весь трафик будет перенаправлен на страницу /maintenance.html, при этом сохраняя правильный код статуса для HTTP-заголовка.


Материал изложен в форме авторского перевода.
Оригинал текста расположен на сайте «Ma.ttias.be»