Частка пошукового індексу сайту - seo форум
Друзі, щоб першими отримувати повідомлення про ось таких ось пізнавальних матеріалах на форумі, підписуйтесь на наш канал в Telegram
Нерідкі випадки, коли пошукові системи індексують на сайті велика кількість сторінок, що не несуть з їх точки зору корисної інформації - чіткі або нечіткі дублікати сторінок, технічний сміття, службові сторінки і т.п. Ці сторінки можуть стати перешкодою для своєчасної переиндексации і коректного ранжирування сайту, тому дуже бажано мінімізувати їх кількість в індексі. Зробити це можна різними способами, які можна розбити на дві великі групи: заборона до індексації і склейка з іншими сторінками сайту. Розглянемо особливості кожного із способів і кращі варіанти їх застосування.
Основна відмінність заборони і склейки полягає в тому, що в разі склейки, нетекстові характеристики підклеює сторінки (назвемо її неканонічною), такі як значення посилальних, поведінкових і тимчасових факторів, будуть підсумовані зі значеннями відповідних факторів цільової сторінки (назвемо її канонічної). У разі ж заборони індексації, вся ця інформація буде просто втрачена. Тому забороняти до індексації в першу чергу має сенс ті сторінки, які не мають скільки-небудь значущих значень нетекстових характеристик, наприклад, відсутні прямі посилання на них, а кількість трафіку на цих сторінках зовсім небагато. Як правило, це спеціальні сторінки, наприклад, rss-стрічка, особисті кабінети користувачів або результати пошуку по сайту.
Заборона індексації сторінки можна здійснити наступними способами:- За допомогою директиви Disallow в секції для відповідного юзер-агента пошукача файлу robots.txt
- За допомогою значення noindex директиви content мета тега robots
У першому випадку не буде витрачатися краулінговий бюджет, виділений на переіндексацію сторінок сайту, що мають відгук 200 OK, так як індексує робот просто не буде звертатися до заборонених в файлі robots.txt сторінок. Тому цей спосіб в загальному випадку потребує менше часу. У другому випадку робот буде завантажувати сторінки, і тільки після їх скачки буде виявлена забороняє індексацію директива. Таким чином, краулінговий бюджет сайту буде частково витрачатися на постійну переіндексацію подібних сторінок.
301-й редирект застосуємо в тих випадках, коли вміст неканонічною сторінки повністю ідентично вмісту канонічної, тому в цьому випадку користувача можна просто перенаправити з одного URL на інший. В цьому випадку при зверненні до неканоническому URL не відбувається витрати краулінгового бюджету, так як він має відгук, відмінний від 200. Слід мати на увазі, що в разі використання редиректу з відгуком 302, склейки не відбудеться.
Цей спосіб доцільно застосовувати, наприклад, при зміні структури URL сайту або для склеювання дублів URL зі Слеш на кінці і без нього. Якщо ж по неканоническому URL необхідно віддавати користувачеві вміст, тобто він повинен мати відгук 200, то в цьому випадку необхідно використовувати два інших способи склейки.
Використання директиви Clean-param в файлі robots.txt обмежується тільки сторінками, що мають в URL динамічні параметри. Це можуть бути як параметри, які не впливають на вміст (наприклад, ідентифікатори сесій або Реферер), так і впливають (наприклад, режими сортування). Неканонічний URL підклеюється до канонічного, який утворений шляхом видалення зазначених у директиві параметрів. Природно, що такий канонічний URL повинен мати відгук 200, інакше ніякої склейки не відбудеться.
Даний спосіб також не приводить до витрати краулінгового бюджету, тому що в цьому випадку пошуковий робот просто не буде завантажувати неканонічний URL. Однак, треба мати на увазі, що з цієї ж причини пошуковику будуть невідомі посилання, що знаходяться на неканонічному URL. Тому доцільно застосовувати цей спосіб у випадках, коли «обрізаються» параметри не впливають на вміст сторінки або значень цих параметрів може бути досить багато, щоб зробити помітний вплив на витрату краулінгового бюджету (наприклад, результати пошуку по сайту).
І нарешті, третій варіант. який мені видається в багатьох випадках найкращим - це використання атрибута canonical тега . До плюсів цього методу відноситься те, що, як і за будь-якої склейці, відбувається підсумовування нетекстових чинників неканонічною і канонічної сторінок (що, до речі, безпосередньо підтверджено співробітником Яндекса Олександром Смирновим на Шостий Вебмастерской) плюс відбувається облік посилань, які перебувають на неканонічною сторінці (що також було безпосередньо підтверджено в блозі збірного образу служби підтримки Яндекса Платона Щукіна).
Єдиний мінус цього методу - це те, що неканонічні сторінки в силу того, що вони мають відгук 200, так само, як і в випадку з noindex в мета-теге robots, обиратимуть краулінговий бюджет. І так само неканонічна сторінка може досить тривалий час знаходиться в індексі до того моменту, як буде склеєна з канонічної.
Проте даний спосіб відмінно підходить, наприклад, для склеювання сторінок пагінацію, різних варіантів сортування, результатів застосування фільтрів до списків і т.п. а також «обрізання» динамічних параметрів URL. До речі, що стосується пагінацію, то співробітники Google рекомендують використовувати атрибути rel = "next" і rel = "prev» тега . Однак Яндекс не підтримує ці директиви. Тому я все-таки рекомендую використовувати rel = "canonical" для обох пошукових систем, тим більше, що практика показує, що ця директива прекрасно працює і в Google. Є відмінність між Яндексом і Google і безпосередньо в обробці директиви rel = "canonical" - Яндекс, на відміну від Google, не підтримує крос-доменних цієї директиви, тобто не можна склеїти сторінки, що знаходяться на різних піддоменів.
І на закінчення хотілося б відзначити, що слід уникати багаторазового послідовного застосування директив склейки. Наприклад, ланцюжків редиректів або вказівки в якості канонічної сторінки, яка сама містить директиву rel = "canonical" на з зазначенням третю сторінку. Так само як і послідовно комбінувати різні методи склейки. Наприклад, коли URL, що виходить в результаті «обрізання» параметрів за допомогою директиви Clean-param, в свою чергу є неканонічним. У подібних випадках пошукова система може просто проігнорувати директиви.
Офіційний канал MaulTalk в Telegram