Здрастуйте, шановні читачі блогу . Трохи раніше ми встигли з вами поговорити про дзеркалах, дублях сторінок і їх видалення.
Давайте сьогодні продовжимо тему і подивимося яким чином пошукові роботи взаємодію з нашими сайтами, щоб зрозуміти, на які речі потрібно обов’язково звертати увагу і, у випадку виявлення помилок, обов’язково виправляти.
Здавалося б, що мова Http запитів та відповідей сервера (сервер — це ПО на хостингу) настільки далекий від SEO, що витрачати час на розуміння його принципів буде жахливим марнотратством. Однак, це не так.
Багато речей, не помітні при побіжному погляді через браузер, можуть надавати значний вплив на просування вашого сайту (аж до його повного випадання з індексу). Побачити всі ці недоліки можна, лише зрозумівши, де і що саме потрібно дивитися.
Http запити — як пошуковий робот спілкується з сервером
Тепер для продовження розмови на тему, нам треба буде подивитися в сторони роботи браузерів. Я вже досить докладно писав, що таке браузер, але якщо говорити коротко, то це програма для перегляду Html-сторінок, завантажених з інтернету. Але нас зараз цікавить конкретне питання: як відбувається взаємодія браузера та сайту?
Браузер (пошуковий бот) і сервер спілкуються по протоколу Http
Після того, як ви ввели Url в адресному рядку браузера (або, що те ж саме, перейшли по посиланню, або відкрили закладку), він звертається до згаданого вище DNS сервера (найближчого), щоб той повідомив браузеру IP адресу, що відповідає введеному доменного імені сайту.
Правда, браузер спочатку до файлу Hosts звертається і в свій ДНС кеш заглядає, але якщо там нічого з цього домену не знаходить, то починає ломитися в найближчий ДНС сервер (зазвичай він знаходиться у вашого інтернет-провайдера).
В DNS серверах зберігаються таблиці відповідності доменів і відповідних їм IP адрес серверів (комп’ютерів, завжди підключені до інтернету), де фізично розміщуються файли сайтів. Отримавши шуканий IP адреса, браузер HTTP робить запит до сервера з цією адресою.
Для передачі даних у такому запиті можуть використовуватися два методи: Get або Post. У звичайних випадках використовується Get, і якщо утрирувати, то для нашого прикладу такий запит може виглядати так (вказується відносний URL адреса сторінки — щодо кореня сервера):
Get /papka/fail.html HTTP/1.1
Цей запит йде на IP адресу, отриманий раніше від ДНС сервера. На сервері встановлено програмне забезпечення (найчастіше Апач), яке, отримавши такий запит, знаходить потрібний файл за вказаною відносного шляху і відправляє його (у вигляді Html-коду) назад в браузер.
Браузер, у свою чергу, цей Html код інтерпретує в веб-сторінку з урахуванням CSS стилів, які могли бути задані як в самому Html коді, так і в зовнішньому файлі стилів, який теж буде довантажений.
А як відбувається взаємодія пошукового робота з сайтом? По суті, точно так само. Робот відправляє запит на ДНС сервер і отримавши IP відправляє Get запит із зазначенням відносного шляху до потрібного йому файлика вебсторінок. Сервер обробляє запит, знаходить файлик і відправляє її в Html вигляді пошуковому роботу.
Тобто відмінностей фактично немає, бо пошуковий робот — це той же самий браузер, в якого за непотрібністю відсутній графічний інтерфейс (Html сторінки він просто завантажує, але не відкриває). Крім цього, бот не виконує Джава-скрипти і не завантажує картинки (їх індексацією займається спеціальних бот). Але це вже деталі.
Отже, розібравшись у методах спілкування браузера з сервером, ми зрозуміємо, як пошуковий робот спілкується з нашим сайтом і які проблеми на цьому рівні можуть виникати, викликаючи серйозні перешкоди успішному просуванню.
Чому так важливо перевіряти HTTP заголовки запитів до вашого сайту
Подивитися HTTP заголовок можна різними способами. Наприклад, я використовую розширення для браузера Хром під назвою HTTP Headers, але подібних аналогів море.
Браузер формує запит HTTP типу Get, де вказується відносний шлях до вебсторінки та версія цього протоколу, за якої готовий працювати браузер (зазвичай це 1.1):
Get /papka/fail.html HTTP/1.1
Ось такий заголовок формується браузером (він у верхній половині екрана) при переході на сторінку мого сайту з пошукової видачі Яндекса:
З нього можна, наприклад, дізнатися, звідки був здійснений перехід на потрібну сторінку за допомогою міститься в полі Referer інформації). Також зверніть увагу на полі User Agent. Кожен браузер і кожен пошукових має свій власний User Agent, за яким його можна ідентифікувати на сервері.
Юзер агенти браузерів досить-таки довгі (там спочатку йдуть перерахування всякої всячини, а безпосередньо назву браузера йде в самому кінці), а ось у ботів вони складаються з одного або декількох слів.
Правильні відповіді сервера Http запити — запорука успішного SEO
У нижній частині скріншота показаний відповідь сервера на запит HTTP браузера. Саме на підставі відповіді сервера пошуковий робот буде любити цю сторінку, або буде її ігнорити. На цьому скріншоті початкова (найважливіша) рядок відповіді сервера показана вгорі під початком запиту браузера і виглядає так:
HTTP/1.1 200 OK
У цьому відповіді вказується протокол, який запросив пошуковий робот (або браузер), а далі йде вже безпосередньо код відповіді сервера. Якщо ви пам’ятаєте, то про Http коди відповіді я вже писав, але тут все ж таки повторюся, щоб не створювати вам незручності. Саме цей код відповіді сервера визначає подальші дії робота-індексатора цієї сторінки вашого сайту.
Крім коду, у відповіді сервера можна знайти і ще низка корисної інформації. Наприклад, назва програмного забезпечення (в полі Server), на якому цей сервер працює (найчастіше зустрічається Апач, nginx або microsoft). Тип контенту (Content-Type) теж дуже важливий для пошукового робота, бо він індексує не всі.
Також дуже важливим є поле Last-Modified. Плагін HTTP Headers його не показує, але ви можете ввести Url сторінки в цей сервіс та дізнатися значення Last-Modified для вас цікавить сторінки будь-якого сайту (найчастіше потрібна інформація саме по своєму ресурсу).
Орієнтуючись на нього, пошуковий робот може зрозуміти, з’явилося на цій сторінці щось нове, що мало б сенс її переіндексувати, або все залишилося по-старому з моменту його попереднього заходу.
Заголовок відповіді сервера містить ще ряд полів, після чого слід вже безпосередньо Html код веб-сторінки, яку і повинен буде зберегти робот у разі отримання правильного коду відповіді (200) або в разі нової дати у полі Last-Modified для раніше проіндексованої сторінки.
Http коди відповіді сервера та їх вплив на SEO просування
Основне завдання вебмастера (і оптимізатора теж) полягає в тому, щоб у цьому заголовку сервера не було б чогось такого, що відверне від неї пошукового бота. Йому не важливо, як виглядає сторінка і що на ній міститься найважливіший у світі контент.
Якщо відповідь сервера буде неправильним, то бот розвернеться і піде далі по своїх справах, залишивши вашу сторінку або весь ресурс не проіндексованим.
А яку відповідь вважати правильними і які варіанти взагалі можливі? Давайте великими мазками розглянемо можливі варіанти.
Коди відповіді діляться по сотнях, тобто, припустимо, до четырехсотым помилок належать 401, 402, 403. Коротко це буде виглядати так:
Наше завдання, як вебмайстрів і оптимізаторів, полягає в тому, щоб всі просувні сторінки віддавали б правильні коди відповіді сервера (200 або, на худий кінець, 301, якщо сторінка поміняла свій Урл з якихось причин).
І що не менш важливо, усі сторінки, які з якихось причин були проставлені неправильні Урли (вони можуть розташовуватися не тільки на вашому сайті), віддавали б код помилки 404. Якщо неіснуючі веб-сторінки будуть віддавати код 200, то це може завдати непоправної шкоди сайту і просувати його засобами СЕО буде важко.
У статті про перевірку сайту я згадував набір загальнодоступних інструментів з арсеналу Яндекс Вебмастера. Є там і сервіс «Перевірка відповіді сервера«. Вставте в його форму будь Урл з вашого сайту і навмисно його зіпсуєте (додайте в ту частину адреси, що міститься після доменного імені, яку-небудь нісенітницю).
Якщо у відповідь ви побачите код відповіді 404, то значить ваш сервер правильно обробляє не знайдені сторінки, а якщо щось інше, то потрібно шукати причину несправності.
Правда, в разі WordPress може видаватися код 301 редіректу, якщо ви нісенітницю введете в ту частину Урла, яка відповідає за рубрику (це така особливість роботи двигуна, що дозволяє переміщати статті між рубриками, не переживаючи про ручний простановке 301 редіректу — все робиться автоматично самим движком).
Як тупий сервер може запороти ваше розумне SEO
Є ще цілий ряд особливостей у спілкуванні між сервером і пошуковим ботом, які можуть звести нанівець усі ваші майбутні та поточні зусилля по просуванню. Ці речі здаються дріб’язковими і досить-таки складно-незрозумілими, щоб більшість вебмайстрів і оптимізаторів на них зосереджувалася. Однак, воно того варте:
Content-Type: text/html;charset=UTF-8
Воно говорить про те, що наявний на сервері документ являє собою Html-файл у кодуванні російської мови UTF-8. Правильне вказівку кодування дуже важливо, бо може викликати як проблему з прочитання матеріалів сайту користувачами, так і складнощі в її сприйнятті пошуковими роботами.
Бот просто читає вміст charset, і якщо воно з якихось причин не буде відповідати реально використовуваної в тексті кодуванні, то завантажені кракозябры, природно, ні в індекс, ні видачу не потраплять. Що сумно, бо надалі пошуковий робот, швидше за все, вже на цю сторінку заходити не буде, бо там нічого цінного немає.
Last-Modified — другий камінь спотикання (із сонму http відповідей веб-сервера пошуковому боту), що впливає на просування сайту. У цьому полі вказується дата зміни документа (останнього оновлення інформації на веб-сторінці). Робот обов’язково дивися в це поле, бо в нього багато роботи і відволікатися на перегляд документа, який не змінився з моменту його останнього відвідування, було б нерозумно.
Пошуковий робот робить серверу запит на завантаження сторінки — була та змінена за час, що минув з його останнього приходу (відправляється в поле if-modified-since з датою останнього завантаження документа цим роботом). Сервер це звернення обробляє, і якщо сторінка з тих пір була дійсно змінена (зчитується Last-Modified і порівнюється з датою отриманої від робота), то він віддає її вміст боту (код 200 у відповідь, природно). Пошуковий індексатор її переіндексірует і будуть враховані всі внесені зміни, наприклад, доданий контент або посилання.
В іншому випадку (коли Last-Modified не змінювався) сервер віддає боту лише код 304. У цьому випадку робот зі спокійною душею піде далі. Проблема може полягати в тому, що сторінку ви могли вже за цей час десять разів змінити, але в індексі пошуковика вона не оновиться, бо не оновлювався Last-Modified для цього файлу. CMS (движки сайтів) досить часто цим грішать, потрібно обов’язково все це перевіряти і при необхідності налаштовувати. Як? Це вже інше питання.
Головне, щоб ви зрозуміли де і що дивитися, щоб вчасно помітити помилку (дивіться другий з попередніх скріншотів). Виправляти її потрібно буде вже виходячи з ситуації (типу вашої CMS, типу програмного забезпечення сервера тощо).
Почати можна з звернення до хостеру з проханням допомогти (безкоштовно або за гроші) у вирішення проблеми. Для них це, як правило, не проблема. Але ви, по-перше, повинні самі зрозуміти, що у вас ця проблема є, а по-друге, повинні дохідливо пояснити її суть адміністратора сервера.
301 і 302 редиректи (коди відповіді сервера) їх використання
Буває, що з якихось причин ви хочете змінити Url-адресу сторінки. Наприклад, як вже згадував трохи вище, захочете перенести статтю з однієї рубрики в іншу (при певному алгоритмі формування ЧПУ це може спричинити за собою зміну Урла). Причин зміни Урлов може бути маса (хоча б перехід з протоколу http на захищений протокол https).
Не залежно від причини вам важливо, щоб при переході по старому Урл адресою користувач потрапляв на потрібну веб-сторінку, а не милувався вашої пречудовий сторінкою 404 помилки.
Який редирект використовувати при зміні Урл адреси сторінок?
Як це зробити? В загальному-то не складно, але важливо, щоб сервер при цьому видавав правильний код відповіді (301). Варіантів коду відповіді для редиректа (перенаправлення) при цьому зазвичай використовується два:
Якщо ви не робите 301 редирект, а просто міняєте Url сторінки, то втрачаєте положення (позицію) у видачі, бо старий урл, що живе в індексі пошуковика, буде віддавати 404 код відповіді, а значить з часом буде видалений з індексу.
Новий же Урл повинен бути спочатку проіндексований, потім ще вам доведеться набирати заново посилальну масу, чекати місяці, і то не факт, що все повернеться туди, де і було. Далеко не факт. Тому при зміні Урла обов’язково робіть 301 редирект зі старого Урла на новий і буде вам щастя.
Особливо це важливо, коли переходите на новий движок сайту (або переносите розділи), тобто коли змінюються Урли всіх сторінок відразу, як, наприклад, при зміні доменного імені або переездt сайту на захищений протокол Https.
У таких випадках обов’язково потрібно робити посторінковий 301 редирект, інакше втратите весь трафік на дуже тривалий період часу. Причому навіть після відновлення він може повернутися не повністю. А при 301 редірект, швидше за все, все пройде «чинно і благородно», тобто практично непомітно в плані зниження трафіку з пошукових систем.
Вся наявна зовнішня посилальна маса поступово перейде на нові Урли. 301 редирект встановлюється на постійній основі незважаючи на те, що в індексі пошуковика з часом старих Урлов вже не залишиться.
Сервера бувають різні і редиректи у них налаштовуються по різному
Сервер, по суті, той же комп’ютер, тільки в особливому (серверному) виконанні. У нього є материнська плата, жорсткі диски, процесор і оперативна пам’ять. Хіба що тільки немає персонального монітора. Програмне забезпечення на нього ставиться теж серверне.
Віндовс на веб-серверах використовується не часто, бо ця ОС коштує грошей, у той час як більшість аналогів зі світу Лінукса безкоштовні (Debian, CentOS, Ubuntu та інші) — от вони і отримали найбільшу популярність.
Але однієї операційної системи для роботи сервера не достатньо. В ОС встановлюється спеціальне програмне забезпечення, серед яких основною програмою є веб-сервер.
Найпопулярнішою з таких програм є Apache (більше трьох чвертей серверів з сайтами в інтернеті працюють на ній), бо вона безкоштовна, постійно оновлювана, добре оттестировать і має велику кількість розширень.
Перед Apache іноді ставлять ще й Nginx (як і у випадку з цим блогом), який є проксі сервером. Це, до речі, вітчизняна розробка, поступово завойовує весь світ.
Крім програми веб-сервера встановлюються ще й інтерпретатори різних мов серверного програмування. Багато CMS написані на PHP (Joomla, WordPress) і без інтерпретатора мови працювати не будуть, але також є і інші.
Ну і, звичайно ж, бази даних теж потрібні для багатьох движків. Найбільш поширена MySql, але є й інші різновиди, як MSSql, Оракл. Ще щось може бути встановлено для вирішення специфічних завдань.
З високою ймовірністю ваш сайт буде працювати під управлінням веб-сервера Apache, а саме він формує коди відповіді сервера, про яких ми говорили трохи вище.
Особливістю роботи з такими середовищами є те, що:
htaccess файл полегшує керування сервером Apache
У веб-сервера Apache основний конфігураційний файл називається httpd.conf. Однак, якщо в ньому прописана роздільна директива, то для кожного каталогу сайту на вашому сервері можна буде використовувати додатковий файл конфігурації .htaccess.
Можливості у нього такі ж, як і у httpd.conf, але всі прописані в ньому директиви будуть застосовуватись тільки до тієї папки, у якій він знаходиться.
Однак, якщо додайте файл .htaccess в корені, то його дія пошириться на весь ваш сайт. Цей спосіб конфігурації Apache зручний тим, що доступ до .htaccess, що лежить в корені сайту, можна отримати по звичайному ФТП з’єднанню з допомогою будь-якого ФТП клієнта. Редагувати ж його можна в будь-якому текстовому або Html редакторі (в тому числі і в онлайн редакторі).
Якщо у вас в кореневій директорії .htaccess немає, то просто створіть у себе на комп’ютері порожній текстовий файл і збережіть його без розширення та з точкою перед назвою htaccess. Після цього підключіться до сайту по ФТП і скопіюйте даний порожній файлик в кореневу папку. Потім по мірі необхідності відкривайте його і внесіть потрібні вам інструкції, які з превеликим задоволення виконає веб-сервер Apache.
Однак, настійно рекомендую перед кожною правкою .htaccess зберігати його до себе на комп’ютер, бо з-за помилки у вноситься інструкції може стати недоступним весь сайт. Маючи бекап, ви зможете відновити все як було в лічені секунди. Ну і також раджу виправлення вносити не в звичайному блокноті Віндовс, а в редакторі на кшталт Notepad++, де є можливість відкотитися назад.
Що ж саме можна прописувати в .htaccess? Дуже багато всього, і для повного та самостійного розуміння суті вам доведеться зануритися в світ адміністрування серверів і програмування (див. статтю про чарівний файл .htaccess). Дуже часто у таких записах зустрічаються так звані «регулярні вирази», які дозволяють вибірково застосовувати прописані директиви.
Все це потрібно знати, щоб повністю самостійно керувати своїм веб-сервером для реалізації необхідних на сайті функцій. Однак, ніхто вам не заважає користуватися чужими напрацюваннями у величезних кількостях наявних в мережі.
Хорошим прикладом може служити склейка дзеркал через 301 редирект, описана в статті за наведеною посиланням або ж у першій частині даної публікації. Також за допомогою записів .htaccess ми:
Налаштовуємо 301 редирект через файл .htaccess
Нагадаю, що сьогодні ми говоримо про відповіді сервера і 301 редирект, який є абсолютно необхідною річчю в разі зміни Url однієї сторінки або перенесення всього сайту на новий домен, переїзді на Https або при склейці дзеркал. Цей самий редирект найчастіше реалізуються саме за допомогою файлу .htaccess (якщо сайт працює на сервері Apache. Давайте подивимося приклади його реалізації.
Для перенаправлення з одного Урла на інший буде достатньо додавання .htaccess такий ось рядки:
Redirect 301 /old-page.html http://new-domain.ru/new-page.html
У директиві Redirect позначення старої сторінки (з якої йде переадресація) використовується відносний адреса (бо редірект по-любому буде виконуватися на цьому сайті), а для нового Url — абсолютний (бо можна зробити редирект і на сторінку іншого сайту). До речі, замість директиви Redirect 301 можна використовувати RedirectPermanent або Redirect permanent.
Якщо йде переадресація в межах одного домену, то можна використовувати в обох випадках відносні адреси. Ось реальний приклад з .htaccess, що живе в кореневій папці мого блогу (між двома адресами ставиться пробіл):
Redirect 301 /joomla/joomla-3-professionalnyj-sajt-za-odin-den.html /videokursy
Однак, якщо вам потрібно зробити посторінковий редирект (наприклад, для зміни розширення сторінок сайту .html на .php або ще щось, що дозволяє не прописувати окремі рядки 310 редіректу для кожної сторінки), то набагато зручніше використовувати регулярні вирази. Такий спосіб називають пакетним редиректом.
Для цього використовується вже директива RedirectMatch, в якій допускається використання регулярних виразів. Наприклад, для зміни закінчень сторінок .html на .php можна використовувати ось такий код:
RedirectMatch 301 (.*)\.html$ http://www.yourdomain.ru$1.php
Чпу (людинозрозумілі посилання) на сайтах багатьох CMS теж реалізуються з допомогою подібних редиректів. Ну і, звичайно ж, та сама склейка дзеркал, яка виникає через WWW, теж відбувається за рахунок 301 редіректу (з використанням можливостей модуля mod_rewrite веб-сервера Apache):
Редірект на WWW:
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.domain\.ru$ [NC]
RewriteRule ^(.*)$ http://domain.ru/$1 [R=301,L]
Редірект з WWW:
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.domain\.ru$ [NC]
RewriteRule ^(.*)$ http://domain.ru/$1 [R=301,L]
Крім можливостей додаткового файлу конфігурації Apache (.htaccess) для створення редиректів використовують і інші методи, реалізовані на можливостях різних мов програмування (PHP, Javascript та інших). Навіть засобами Html можливо зробити перенаправлення (правда, не знаю, як це буде сприйматися пошуковими системами). Про це я писав у статті про те, як можна приховати партнерську посилання.
Удачі вам! До зустрічей на сторінках блогу
