Заказать SEO-услуги
Согласен с правилами обработки персональных данных
Скорость ответа - до 30 минут!

Блог(укр)    Технічні аспекти    Технічні помилки, які допускають оптимізатори

Технічні помилки, які допускають оптимізатори

like 62
26
27
9

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

У даній статті ми хотіли б розглянути деякі приклади помилок, які можна зустріти .

1. Помилки Robots.txt

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

1) Прогалини

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

Неправильно:

User-agent: Yandex

Disallow: /system
Disallow: /admin
Disallow: /login
Disallow: /logout

або

User-agent: Yandex
Disallow: /system
Disallow: /admin

Disallow: /login
Disallow: /logout

Правильно:

User-agent: Yandex
Disallow: /system
Disallow: /admin
Disallow: /login
Disallow: /logout

Пропуск допустимий у даному випадку тільки після закінчення всіх команд для одного User-agent. Після цього ставиться пробіл і можна використовувати новий User-agent.

Приклад:

User-agent: Yandex
Disallow: /system
Disallow: /admin
Disallow: /login
Disallow: /logout

User-agent: Google
Disallow: /system
Disallow: /admin
Disallow: /login
Disallow: /logout

2) Директива Host

Дана директива належить пошуковій системі Яндексу і необхідна для визначення головного дзеркала сайту. Її краще розміщувати в кінці чи максимально близько до кінця.

Неправильно:

User-agent: Yandex
Host: www.site.ru
Disallow: /system
Disallow: /admin
Disallow: /login
Disallow: /logout

Правильно:

User-agent: Yandex
Disallow: /system
Disallow: /admin
Disallow: /login
Disallow: /logout
Host: www.site.ru

3) Використання Allow

Використання Allow не є обов’язковим пунктом під час складання файлу robots.txt. Дана команда доречна тільки у зв’язці з використанням команди Disallow.

Неправильно:

User-agent: *
Allow: /content/photo

Правильно:

User-agent: *
Disallow: /content
Allow: /content/photo

2. Дублі сторінок

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

Самі дублі можна розділити на технічні та змістові.

Смислові дублі виникають або через навмисні спроби «обману» пошукової системи (написання схожого за змістом тексту), або через неправильну побудову структури сайту.

Технічні дублі – це, в основному, дублі, створені автоматично, дублі через неправильне використання CMS сайту.

Знайти технічно дублі досить легко, використовуючи пошуковик. Якщо вам потрібно визначити, чи немає дубля у головної сторінки сайту типу www.site.ru/index.php, це можна легко перевірити.

Введіть у будь-якому пошуковику, наприклад, site: www.site.ru/ і site: www.site.ru/index.php. Якщо обидві сторінки в індексі, значить, у вас є дублі.

Якщо ви хочете скористатися пошуком тільки певної частини URL (наприклад, URL, частиною імені якого є слово index), вам необхідно буде набрати наступне:

site: www.site.ru inurl: index

Пошуковик покаже вам усі можливі варіанти сторінок в індексі з використанням даного збігу в URL.

3. Використання атрибуту rel=”canonical”

Даний атрибут використовується в тих випадках, якщо є кілька сторінок зі схожим контентом і необхідно визначити, яка зі сторінок є головною або, як кажуть, «канонічною». rel = “canonical” розташовується на сторінці, яку ви вважаєте головною. Наприклад, у вас є сторінки блогу, які важливі для вашого сайту, але вони містять дубльовану інформацію, наприклад, анонси статей. У такому випадку даний атрибут можна встановити на першій сторінці блогу. Але цей атрибут необхідно застосовувати у виняткових випадках (як і команду Allow в robots.txt), коли немає іншої можливості унікалізувати сторінку.

Даний атрибут також може бути неправильно використаний.

Неправильно:

www.site.ru/blog (<link rel=”canonical” href=” www.site.ru/blog/1″>)
www.site.ru/blog/1
www.site.ru/blog/2

або

www.site.ru/blog
www.site.ru/blog/1(<link rel=”canonical” href=” www.site.ru/blog/1″>)
www.site.ru/blog/2

Правильно:

www.site.ru/blog (<link rel=”canonical” href=” www.site.ru/blog”>)
www.site.ru/blog/1
www.site.ru/blog/2

або

www.site.ru/blog
www.site.ru/blog/1(<link rel=”canonical” href=” www.site.ru/blog”>)
www.site.ru/blog/2

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

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

4. Редирект 301

Використання 301 редиректу для сторінок дозволяє перенаправити користувача зі старого посилання на нове, де, власне, і знаходиться сторінка. Однак і тут можуть спостерігатися деякі проблеми.

По-перше, даний редирект не завжди варто використовувати.

Не потрібно використовувати, якщо:

1) Проводяться тимчасові зміни
Наприклад, якщо ви вирішили зробити якісь тимчасові зміни на сайті, робити редирект 301 на сторінку зовсім не обов’язково. Замість цього можна скористатися командою 302 moved temporary («тимчасове переміщення»).

2) Сайт під баном або фільтром
У такій ситуації багато людей роблять досить нехитрий хід. Вони реєструють новий домен і роблять редирект зі старого домену на новий. Так ось цього робити категорично не варто, оскільки в даному випадку всі проблеми вашого старого сайту перейдуть на новий.

3) Вже був застосований один із способів для 301 редиректу
301 редирект можна робити кількома різними способами через htaccess, php, javascript, налаштування серверу і т.д. Ви повинні переконатися, що редирект буде проводитися якимось одним із перерахованих способів.

Коли варто використовувати внутрішні редиректи:

1) Редирект з “без www” на “www” і навпаки – з “www” на “без www”
Це один з найпоширеніших видів використання редиректів, який дозволяє «склеїти» сторінки з www.

2) Редирект з однієї сторінки на іншу
Тут також все зрозуміло – ви перенаправляє з однієї сторінки на іншу: із внутрішньої на внутрішню, на головну чи навпаки.

3) Редирект для розширення файлів (наприклад, усі файли .html на .php)
Ця процедура також проводиться під час оновлення всього сайту та зазвичай у даному випадку налаштовують 301 редирект одночасно для всіх сторінок.
Краще зайвий раз не полінуватися та переробити посилання, якщо вона внутрішня. Повірте, зробивши редирект один раз, ви потім будете користуватися даними способом за замовчуванням і, рано чи пізно, створите заплутану структуру, ланцюжків редиректів.

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

Подписаться на рассылку

Еще по теме:


Никита П.

SEO-аналитик

Оцените мою статью: 

1 Star2 Stars3 Stars4 Stars5 Stars (6 оценок, среднее: 4,67 из 5)

Есть вопросы?

Задайте их прямо сейчас, и мы ответим в течение 8 рабочих часов.

Наверх