Як правильно розмітити різні версії одного і того ж документа, які не є канонічними

Випадок використання - це документ, який має декілька версій, які одночасно доступні. Наприклад, документація на продукт для кожної версії цього програмного забезпечення:

• /v1/install-guide
• /v2/install-guide
• /v3/install-guide

Це не той самий зміст у тому сенсі, що було б неправильно вказати на сторінках v1 та v2, що канонічна URL-адреса v3. Якщо б я шукав в Google "посібник з встановлення продукту v2", я б очікував, що зможу знайти v2. Кожна версія документа була б дещо різною, але вони мали б багато спільного між собою.

Отже, питання: чи можу я позначати ці сторінки якимось чином, щоб повідомити Google та друзям про те, що краща остання версія (v3), тому простий пошук "посібника з встановлення продукту" швидше показуватиме сторінку v3 замість сторінка v1 чи v2?

Враховуючи ваше запитання, я повинен зробити такі припущення:

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

По-перше: це справді не той випадок використання для rel="canonical" .

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

Схема:

exapmle.com/product/guide/
exapmle.com/product/guide/guide-v1
exapmle.com/product/guide/guide-v2
exapmle.com/product/guide/guide-v3

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

Переконайтесь, що v1, 2, 3, … n версії пов'язані лише з основної сторінки посібників та кожної з них. Головна сторінка повинна бути добре пов’язана на всьому веб-сайті.

Порівняно з існуючою структурою URL-адрес, це надає більшої актуальності посібнику, опублікованому в exapmle.com/product/guide/.

• /v1/install-guide
• /v2/install-guide
• /v3/install-guide

У цій структурі кожна URL-адреса "стоїть" однаковою, і Google повинен розраховувати на інші сигнали, щоб вирішити, яка URL-адреса є найбільш релевантною.

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

• індивідуалізувати заголовок сторінки, наприклад: <title>Version 1.0 install Guide for Product XY</title>
• індивідуалізувати головний заголовок сторінки, наприклад: <h1>How to Install Version 1.0 of Product XY</h1>
• індивідуалізувати опис сторінки, наприклад: <meta name="description" content"Here you can find your guide to install version 1.0 of Product XY […]" />
• використовуйте тексти якоря, щоб вказати на різні версії при посиланні на напрямні <a href="http://example.com/product/guide/guide-v2" >Install guide for V 2.0</a>

Кожен повинен вказати на версію, для якої він був розроблений, і, можливо, рік / місяць / дату.

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

Таким чином ви переконайтеся, що найновіший посібник завжди присутній example.com/product/guide/і буде слугувати результатом для загальних пошукових запитів на зразок " встановити довідковий продукт ". Пошукові системи розпізнають, що вміст на цій сторінці оновлюється часто, а також визнають, що підпункти цих сторінок існують, і подаватимуть їх для більш конкретних пошукових термінів, таких як " посібник із встановлення продукту V 2.0 ". Оптимізуючи сторінки для конкретних версій, які вони представляють, ви переконайтеся, що клієнти знаходять їх версію, шукаючи її.

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

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

Перший веб-сайт, на якому я побачив, що ця практика явно виникає, був W3C. Наприклад, у цього документа вгорі є "остання версія": https://www.w3.org/TR/html401/

Тепер я помітив це у MSDN, де у них є посилання під назвою "Рекомендована версія". https://msdn.microsoft.com/en-us/library/78zh94ax%28v=vs.71%29.aspx

Так чи інакше, я не бачив жодного технічного HTTP або HTML, який би міг використовуватися для позначення такого. Існує тег посилання з rel = "alternate", який може працювати, але я розумію, що справді працює лише для мов або інших різних версій того самого документа, а не різних різних версій.

Є ще одна технологія, з якою спробувала Google, і я впевнений, що вони все ще використовують її, а http://schema.org має тег https://schema.org/softwareVersion . Тож якщо припустити, що Google реалізував саме цей тег, він повинен розуміти вашу версію схеми. Після розуміння Seb, маючи сторінку / guide, ви можете мати посилання на кожну версію. Посилання буде позначене схемою для включення цієї softwareVersionінформації. Тим НЕ менше, ця версія приймає тільки текст змушує мене думати , що це опис ( «Краща версія Ever!») Програмного забезпечення , а не фактичної версії (1.0, 2.3, 3.7.1 ...) Але я думаю , що , ймовірно , буде краще Ви можете зробити.

Я бачив випадки, як ваш, під час перегляду технічної документації, як документи Django .

У цьому випадку немає жодного конкретного тегу, який можна додати, але ви можете використовувати наступні стратегії, щоб натякати Google, що ви віддаєте перевагу посилання v3 (остання версія):

Посилання без версій

• Якщо ви посилаєтесь на цей вміст за межами області v3, використовуйте посилання без версій, які автоматично переспрямовуються на сторінку останньої версії, наприклад:

  example.com/install-guide - переадресація на останню -> example.com/v3/install-guide

Коли у вас є новіша версія (v4), вона буде переспрямована на example.com/v4/install-guide.

Попередження із посиланнями на останню версію

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

Коли Django видаляє версію, вона чітко показує її користувачеві, у вашому випадку ви також можете додати в попередження посилання останньої версії.

Свіжі посилання

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

Щоразу, коли я шукаю будь-яку інформацію про API FB, вона повертає мені останню інформацію з останньою URL-адресою API, і вони не використовують жодних переспрямувань, ані канонічних тегів посилань, які вказують на останню інформацію, те, що вони просто роблять, вони починають вказувати на останню інформацію всюди, тож Google частіше скануватиме та передаватиме більше juicyrank, це єдиний сигнал, який ви також можете використовувати для свого веб-сайту. Ви маєте контроль над своїми посиланнями, тому використовуйте це.

Не використовуйте noindex, перенаправлення 301 та канонічний тег посилань на старих сторінках, які вказують на останню URL-адресу, що зробить вашу веб-сторінку мертвою в очах пошукової системи Google, я маю на увазі, що Google видалить усі початкові переваги, які надаються цій веб-сторінці. Я нещодавно запитав в офіційній відеокімнаті Google, і вони сказали, що вони не дають ніякого початкового значення PR для тегу noindex, тому, думаю, це буде стосуватися і канонічного тегу посилань. і коли ви перейдете 301, весь PR перейде до нової URL-адреси, і будь-який початковий PR буде наданий цій старій веб-сторінці, буде видалено, оскільки вона більше не доступна. Google надає деяку цінність тим веб-сторінкам, які є в прямому ефірі.

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

Ви можете використовувати дату сторінки для сортування.

Google оцінює дату сторінки на основі функцій сторінки, таких як дати в заголовку та URL-адресі.

Спеціальний пошук дозволяє використовувати цю дату для сортування, зміщення та обмеження діапазону результатів за допомогою спеціального ключа метаданих дати. Цю приблизну дату можна використовувати в усіх операторах, які використовують &sort=параметр URL-адреси, включаючи "Сортувати за атрибутом", "Зміщення за атрибутом", "Обмежити діапазон".

Наприклад:

Щоб переглянути список поточних кодів, відвідайте документацію Google Custom Search .