Користь дати в сегментах URL-адрес

Мені було цікаво про дату в сегментах URL-адрес, чи є якась користь для SEO? Наприклад, такі URL-адреси:

http://techcrunch.com/2013/06/18/netflix-will-launch-in-the-netherlands-later-this-year-as-its-international-expansion-slows/
http://tips-for-new-bloggers.blogspot.in/2007/02/adding-favicon-icon-to-blogger-url.html 
https://community.jivesoftware.com/blogs/jivespace/2013/05/15/eol-of-the-html5-ipad-web-app

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

( Подібне запитання було закрито як дублікат, але ОП не цікавився виключно SEO, тому тут приходить відповідь про загальні переваги.)

Включення дати публікації в URL може бути хорошим дизайном URL-адреси .

Корисність: описові URL-адреси

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

• http://blog.example.com/review-of-my-new-laptop
• http://blog.example.com/2011/08/21/review-of-my-new-laptop

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

Звичайно, це не повинно бути корисним лише для користувачів. Споживачі даних (як пошукові системи) також можуть використовувати цю інформацію.

Я не знаю, чи витягують це якісь пошукові системи, але поведінка пошукових систем може часто змінюватися, і їх так багато. Я кажу лише, що це можливість. Очевидним і фактичним випадком є ​​виділення пошукових термінів у СЕРП. Дивіться, наприклад, цей знімок екрана з Пошуку Google, де в даті публікації, що міститься в URL-адресах результатів, виділено "2014":

Корисність: URL-адреси, які можна переглянути

За допомогою URL-адреси http://blog.example.com/2011/08/21/review-of-my-new-laptopкористувачі можуть переглядати, видаляючи сегменти URL-адреси справа наліво:

• http://blog.example.com/2011/08/21/ (усі публікації опубліковані в той же день)
• http://blog.example.com/2011/08/ (всі публікації, опубліковані в тому ж місяці)
• http://blog.example.com/2011/ (всі публікації, опубліковані в тому ж році)

(Якщо ви не хочете дозволити перегляд веб-сторінок, подумайте про те, щоб не використовувати косої риски, а потім, наприклад,. /2011-08-21/)

Реалізація: зіткнення імен

Через кілька років ще один новий ноутбук. Автор не дуже креативний і називає статтю, знову ж таки, "Огляд мого нового ноутбука". Що тепер? Ви можете додати якийсь лічильник до URL-адреси, наприклад

• http://blog.example.com/review-of-my-new-laptop-2, або
• http://blog.example.com/review-of-my-new-laptop/2, або
• http://blog.example.com/2/review-of-my-new-laptop.

Не дуже елегантний. У першому прикладі схоже, що "2" буде частиною заголовка статті (що не так); у другому прикладі, схоже, це було б на сторінці 2 статті; в останньому прикладі він порушується послідовно (якщо ви не додали /1/для всіх інших URL-адрес з самого початку).

Загальне рішення для цього - додати ідентифікатор (як і 49781для цього самого питання). Але чому б ви хотіли це робити, коли ви могли використовувати дату як своєрідний ідентифікатор? Дата має значення (і може бути корисною для користувачів), ідентифікатор буде непрозорим для користувачів (і марним). Так було б

• http://blog.example.com/2011/08/21/review-of-my-new-laptop
• http://blog.example.com/2014/01/09/review-of-my-new-laptop

замість

• http://blog.example.com/00211812/review-of-my-new-laptop
• http://blog.example.com/02401109/review-of-my-new-laptop

(За припущенням, що в один і той же день не публікуються статті з однаковими назвами.)

Звичайно, це актуально лише для веб-сайтів, які мають в першу чергу корисну дату публікації. Не всі сторінки можуть / повинні мати дату публікації. І навіть коли на сторінці відображаються дати публікації, не обов’язково їх також містити в URL-адресі.

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

Наприклад, у WordPress (функція CMS включена) одним із стандартних параметрів постійної посилання (URL) за замовчуванням є встановлення дат у URL-адресах.

Ось відео від Метта Кеттса, в якому пояснюється, що Google використовує власні способи визначення того, наскільки свіжі URL-адреси, і вам не потрібно використовувати дати в URL-адресах .

Також у згаданих вами прикладах ви можете переглядати сторінки без дат, це не так - Techcrunch перенаправляє вас до URL-адреси з датою, а інші два сайти викидають 404, коли ви видаляєте дати.

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

Немає особливої ​​користі для SEO від того, щоб вказати дату в URL-адресі. Пошукові системи, безумовно, можуть проаналізувати дату, щоб знати, коли стаття була вперше створена, але однаково, якщо дата буде на сторінці, вони б її використали.

Користувачам єдина перевага - вони можуть побачити, скільки років належить публікації, перш ніж натиснути URL-адресу. Це може бути, а може і не вигідно залежно від ситуації. Просто використання короткого «куліка» (можливо, з категорією сегмента) достатньо для користувачів та пошукових систем.

Немає переваги SEO вводити дату в URL, оскільки пошукові системи та користувачі люблять короткі URL-адреси. Єдина причина, яку я бачу, - це уникати повторюваних проблем з URL-адресами (навіть якщо для цієї проблеми я вважаю за краще використовувати idURL-адресу).

Я погоджуюся, що не існує користі для SEO для показу дат у URL-адресі, і хочу зазначити, що такі URL-адреси можуть створювати недоліки SEO .

Ваша відображувана URL-адреса в google SERPS обрізається після максимум 70 символів. Сперечно, що додавання чисел (дат) до рядка URL-адреси розбавляє семантичну читабельність URL-адреси та сприймається інформаційний аромат.

Наприклад, порівняйте:

www.longishdomainname.com/blog/12/22/2015/keyword-rich-article-title-here

longishdomainname.com/keyword-rich-article-title-here

... друга URL-адреса просто виглядає більш чистою, і це сперечається, вона отримає більше кліків, ніж перша. CTR є фактором ранжирування альго.