SEO: Найбільш часто зустрічаються помилки

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


1. Використання конструкцій, що ускладнюють коректне індексування документів
2. Засмічення індексів пошукових машин дублікатами сторінок
3. Помилки, що перешкоджають найбільш повної і швидкої індексації та переіндексації сайту

Розглянемо їх докладніше.

1. Використання конструкцій, що ускладнюють коректне індексування документів.


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


Java-script, Vbscript


Пошукові системи не виконують скрипти, що виконуються на стороні клієнта. В іншому разі їх виконання різко підвищило б навантаження на сервера роботів. Ні Java-script, ні Vbscript на сьогоднішній день не індексуються пошуковими системами. Тому роботи не можуть ні проіндексувати текст, ні знайти посилання, виконані на Java-script або Vbscript. Останнє може бути перешкодою для індексації деяких сторінок сайту (пошукові роботи їх просто не зможуть знайти за посиланнями) і розподілу показників авторитетності усередині сайту. Однак, при вмілому використанні, за допомогою подібних посилань можна маніпулювати розподілом показників авторитетності на ваш розсуд.


Тег <noindex>


Ще простіше приховати текст або посилання можна за допомогою тега <noindex> </ noindex>. Правда, не від усіх пошукачів. Цей тег – виключно вітчизняна розробка. Його враховують всього дві пошукові системи – Яндекс і Рамблер. Код розташований всередині цього тега, в тому числі і посилання, не індексується цими пошуковими системами. Тому треба уникати використання цього тега на сторінках сайту, якщо Ви хочете, щоб вміст сторінки було повністю проіндексовано. Найбільш типовою помилкою є використання цього тега для закриття для індексації елементів навігаційного меню при використанні на сайті локального пошуку, що працює на пошуковому движку mnoGoSearch, що також підтримує цей тег. Знову-таки, при вмілому використанні, за допомогою цього тега можна маніпулювати розподілом показників авторитетності на ваш розсуд або концентрацією ключових слів.


Flash


Також як і скрипти, Flash до недавніх пір не індексувався пошуковими системами і вся ця "краса" не потрапляла в бази пошукових систем. Однак, останнім часом деякі пошукові машини (зокрема, Рамблер і Яндекс) заявили про індексацію Flash. Тим не менше, я б не рекомендував широке використання цієї технології, якщо ви хочете, що б ваші сайти добре ранжирувалися пошуковими машинами.


Фрейми


При спочатку здається привабливості використання фреймів на сайті, на ділі вони обертаються тільки проблемами. І справа не тільки в тому, що на кожній сторінці необхідно скрипти, які в цьому випадку завантажують всю фреймову структуру сайту і відкривають в одному з фреймів ту сторінку, на яку відвідувач прийшов спочатку. Фреймові структури повільніше індексуються. Неясно, як розподіляється у фреймах показники авторитетності. Але якщо вже вам довелося працювати з таким сайтом і немає можливості відмовитися від фреймів, то використовуйте тег <noframes> – його зміст, текст та посилання, індексуються. Але необхідно бути обережним з його використанням. Як і до будь-якого контенту, прихованого від користувача, до змісту <noframes> пошукові системи ставляться з підозрою, і воно досить легко може бути розцінено як спам.


Редіректи


Редірект, тобто перенаправлення користувача без його активних дій на іншу сторінку, буває двох типів: виконується на стороні сервера і на стороні клієнта. Клієнтський редірект – річ взагалі дуже небезпечна, сайт може потрапити в бан-лист просто за його використання. Справа в тому, що редірект на стороні клієнта зазвичай використовується для спаму пошукових систем за допомогою дорвеїв. Роботом індексується як б звичайна сторінка, оптимізована під який-небудь запит, але при зверненні користувача до сторінки його перенаправляють на іншу сторінку.


Редірект, що виконується на стороні сервера, не потрапляє під санкції, але хорошого в ньому теж нічого немає. Справа в тому, що між документом А, на якому стоїть посилання і документом В, на який в кінцевому рахунку потрапляє користувач, знаходиться проміжний документ С. І тому подібна конструкція пошуковою машиною може і не бути розцінена, як посилання з документа А на документ У зі всіма витікаючими наслідками.


Динамічні адреси сторінок


Пошукові системи не можуть знати, яким чином формується кінцевий код сторінок, статичний чи це html або динамічно згенерований. Єдиною ознакою виступає url сторінки. Динамічними сторінками вважаються якщо в їх адресу присутній знак питання або вони мають розширення, відмінне від *. htm або *. html, наприклад *. php, *. jsp, *. pl та інші. Чим погані такі адреси? Справа в тому, що деякі пошукових системи можуть накладати обмеження на індексацію подібних сторінок або на облік посилань з таких сторінок.


Цікавий механізм індексації динамічних сторінок Апортом. У нього для кожного сайту існує квота, на кількість індексованих сторінок (будь-якого типу), яке залежить від індексу цитованості сайту. Тобто кількість індексованих сторінок для сайтів з низьким ІЦ менше, ніж для більш "авторитетних". І тільки у випадку, якщо квота дозволяє проіндексувати всі сторінки з сайту зі статичними адресами і який ще не повністю витрачена, Апортом починають індексуватися сторінки з динамічними адресами.


Заміну динамічних адрес на статичні можна здійснити за допомогою спеціального спеціального модуля mod_rewrite для Apache (докладніше про це модулі можна подивитися тут: http://httpd.apache.org/docs/mod/mod_rewrite.html).



2. Засмічення індексів пошукових машин дублікатами сторінок.


Ідентифікатори сесій в адресах сторінок.


Ідентифікатори сесій використовуються для присвоєння користувачеві унікального позначення і генеруються автоматично при відкритті кожної нової сесії. І кожного разу, при проході по посиланнях сайту робот отримує нову адресу для однієї і тієї ж сторінки. У той же час, перевіряючи вже зберігаються в базі пошукової системи посилання, робот виявляє, що вони як і раніше існують, однак через те, що посилань з інших сторінок на цю більше немає, вага у неї вкрай малий. Поступово в базі пошукової системи з'являється велика кількість дублікатів однієї і тієї ж сторінки, що може призвести до санкцій з боку пошукової системи. Сайт може піддатися "безжальної чисткам", тобто видалення з індексу більшої частини сторінок.


І це не єдина проблема, яка викликається ідентифікаторами сесій. Роботи деяких пошукових систем мають обмеження на кількість індексованих за один свій візит сторінок. І наявність безлічі однакових сторінок з різними адресами, природно, уповільнює індексацію сайту.


Враховуючи вищесказане, необхідно позбавлятися від ідентифікаторів сесій в адресах сторінок, тим більше що в більшості випадків, як показує практика, в їх застосуванні немає необхідності. Якщо ж це неможливо, то такі сторінки необхідно заборонити до індексації, а в разі звернення до документів роботів пошукових машин (їх можна, наприклад, ідентифікувати за значенням поля User-Agent) не генерувати ідентифікатори сесії.


Некоректні відгуки сервера.


Ще однією причиною засмічення бази пошукачів і застосування подальших санкцій може стати неправильне налаштування відгуків сервера, а точніше невірний заголовок сторінки, що повертається сервером.


Документи нормально індексуються пошуковими системами, тільки якщо сервер повертає в заголовку код 200 (ОК). При поверненні сервером кодів 301 (переміщено), 302 (тимчасово переміщено) і 404 (не знайдено) сторінки роботом не індексуються і видаляються з індексу, якщо вони в ньому знаходилися. Типовою помилкою є видача сервером коду 200 (ОК) для неіснуючих сторінок. Наприклад, при запиті по невірному адресою, видається сторінка з текстом про помилку, а HTTP-код при цьому 200. У підсумку ця сторінка багаторазово індексується під різними адресами і при накопиченні великої кількості подібних сторінок в індексі сайт піддається чищенні (у разі Яндекса), при якій він може бути видалений з бази практично цілком. Рамблер може "пессімізіровать" сайт, тобто знизити його в результатах пошуку, нарахувавши йому штрафні бали.


Подивитися, які відгуки видає сервер для конкретної сторінки можна, наприклад, за допомогою спеціальних онлайнових сервісів. Ось адреса одного з них: http://www.searchengineworld.com/cgi-bin/servercheck.cgi.



3. Управління повнотою переіндексації сайту.


Найчастіше розробники сайту не замислюються про те, як забезпечити найбільш швидку і повну індексацію і переіндексацію сторінок сайту. І якщо для порівняно невеликих сайтів розміром у кілька десятків сторінок, це, може бути, і не дуже актуально, то зневажливе ставлення до подібного роду речей у разі сайтів, що містять велику кількість документів, що вимірюється сотнями і тисячами, може призвести до того, що роботи пошукових машин будуть постійно переіндексувати одні й ті ж не змінюються малоінформативні документи, обходячи стороною основний контент сайту. Існує ряд технічних прийомів, дозволяють добитися більш биcтрой та повної індексації і переіндексації сторінок сайту.


Розбиття сайту на піддомени.


Роботи пошукових машин можуть мати обмеження на кількість індексованих за один візит документів з одного сайту. Особливо уповільнюють індексацію швидкозростаючий контент, такий, наприклад, як відвідуваний форум або дошка оголошень. Тому можна порекомендувати такі розділи виносити в піддомени – для них у пошукових машин вже будуть свої квоти і вони не будуть сповільнювати індексацію основних розділів сайту.


Налаштування заголовка відгуку сервера на GET і HEAD з полем If-Modified-Since


Роботи пошукових машин при переіндексації запитують документи з полем If-Modified-Since в якому ставиться дата останньої переіндексації. Для статичних документів сервер самостійно формує коректний відгук на такий запит – 200 ОК, якщо документ змінювався після дати, зазначеної в запиті або 304 Not Modified, якщо не змінювався. У другому випадку робот не буде скачувати документ і оновлювати його у своїй базі.


Однак для динамічних документів, що збираються "на льоту", сервер в змозі видати лише 200 ОК. Тому будь-який динамічний документ буде завантажено та переінексува, включаючи ті, вміст яких реально не мінялося з часу останньої переіндексації. Часом подібні документи можуть вибрати всю квоту, виділену на індексацію. Тобто Пошукова машина не отримає ніякої нової інформації про сайт. Тому бажано в заголовку відгуку на запити GET і HEAD з полем If-Modified-Since для документів, про дату останньої модифікації яких є інформація, примусово видавати відгук 304 Not Modified, якщо дата останньої модифікації раніше, ніж дата, що стоїть у запиті. Тим самим робот отримає інформацію про те, що документ не змінився, і, не завантажуючи його, звернеться до наступного документу в черзі. Якщо у робота є ліміт на кількість викачуваних за один захід документів, то, таким чином, він за один захід скачає більша кількість документів, реально змінених або ще не проіндексованих.

Заборона до індексації неінформативних або дублюючих сторінок сайту.


На сайті може перебувати якийсь кількість сторінок, контент яких абсолютно неінформатівен (наприклад сторінки фотогалереї, містять лише зображення) або дублює вміст інших сторінок (наприклад, різні режими сортування інформації в таблицях). Подібні сторінки доцільно забороняти до індексації з метою більш швидкої і повної переіндексації інших сторінок сайту.


Заборонити сторінку до індексації пошуковою системою можна двома способами: за допомогою мета-тегів або файлу robots.txt Для заборони використовується мета-тег "robots":


<META NAME = "ROBOTS" CONTENT = "значення">


В атрибуті content можна застосовувати наступні директиви:


NOINDEX – забороняє індексацію документа, але дозволяє переходити за посиланнями з нього:


< META NAME=”ROBOTS” CONTENT=”NOINDEX” >


NOFOLLOW – забороняє переходити по посиланнях, але не забороняє індексувати документ:


< META NAME=”ROBOTS” CONTENT=”NOFOLLOW” >


Чи їх комбінацію: NOINDEX, NOFOLLOW – забороняє індексувати документ і переходити з нього за посиланнями:


< META NAME=”ROBOTS” CONTENT=”NOINDEX,NOFOLLOW” >


Якщо потрібно заборонити до індексації розділ або групу файлів з однотипними іменами, то більш зручним способом буде заборона за допомогою robots.txt. Це текстовий файл, який повинен розташовуватися в кореневій директорії сервера, тобто бути доступний за адресою http://імя_сайта.ru/robots.txt


Файл повинен містити одну або декілька записів, розділених одним або декількома пустими рядками. Кожна запис складається з рядків виду:


ім'я_поля: [пропуски] значення [пропуски]


Прогалини є не обов'язковими. Регістр значення поля не враховується. Можуть використовуватися коментарі – символ # означає початок коментаря, кінець рядка – кінець коментаря.


Запис повинен починатися з одного або кількох рядків User-Agent, слідом повинна бути одна або кілька рядків Disallow. Нерозпізнані рядки ігноруються.


У рядку User-Agent вказується ім'я робота пошукової системи, для якої забороняються до індексації сторінки. У Яндекса це yandex, Рамблера – StackRambler, Апорт – aport і у Google – googlebot. Якщо роботів, для того, кого потрібно накласти однаковий заборону декілька, то треба помістити в записі кілька рядків User-Agent одну за одною, в кожній вказавши ім'я відповідного робота. Якщо сторінки необхідно заборонити від індексування усіма роботами, то необхідно використовувати символ *. Такий запис, з полем "User-agent: *" може бути у файлі robots.txt тільки одна.


У кожного запису, також, має бути хоча б одне поле Disallow. У ньому вказується вказується частковий або повний шлях (URL), забороняються сторінок. У рядках з полем Disallow записуються не абсолютні, а відносні префікси, тобто у цьому полі не має зазначатися доменне ім'я сайту – www.сайт.ru Якщо значення Disallow не вказано, то це означає, що може індексуватися все.


Наприклад:


User-Agent: *
Disallow: /sript/


Цей запис забороняє всім роботам індексувати файли, посилання на які містять шлях до директорії / sript /. Для повної заборони індексації використовується символ /. Заборонимо Яндексу індексувати сайт:


User-agent: yandex
Disallow: /


Щоб заборонити роботу відвідування динамічних сторінок, можна використовувати частковий шлях. Повертаючись до ідентифікаторів сесій, для заборони сторінок містять їх в адресі можна використовувати подібну конструкцію:


User-agent: *
Disallow: /page3.php;phpessionid


Сторінка page3.php буде нормально проіндексована, а всі її копії, що починаються на page3.php; phpessionid будуть заборонені до індексації.


Наявність robots.txt на сервері не є обов'язковим, його відсутність, як і порожній файл robots.txt, або неправильно складений, буде інтерпретуватися роботом як дозвіл на повну індексацію сайту.


Повна документація по протоколу файлу robots.txt знаходиться тут: http://www.robotstxt.org/wc/robots.html.


У висновку хочу зазначити, що грамотне рішення всіх розглянутих проблем є виключно важливою і невід'ємною частиною роботи з просування сайту в пошукових машинах, так як зневажливе ставлення до цих питань здатне значно зменшити або навіть звести нанівець ефект від заходів з позиціонування сайту.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*