Як керувати канонічними змінами URL-адреси, як переповнення стека

На сайтах із переповненням стека є всі URL-адреси, які містять назву питання. У HTML він також має канонічний URL для цієї сторінки.

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

Чи є ще щось, що можна активно зробити, щоб змінити адресу ще більш плавною?

seo url canonical-url

— лулалала
джерело

Усі запитання на Stack Exchange містять числовий ідентифікатор (28070 для цього питання), який є єдиним, що однозначно ідентифікує питання.

Отже, коли змінено назву питання, URL-адреса, яка як і /28070/old-question-titleраніше, показує питання, оскільки ідентифікатор все ще є. Ідентифікатор переглядається та повертається новий заголовок, тобто нова URL-адреса може бути визначена та показана в канонічному тезі.

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

— Невдоволений козак
джерело

Це нагадує мені класичний аргумент дизайну бази даних щодо того, чи повинні первинні ключі бути значимими або безглуздими. З одного боку, багатьом класам об'єктів, здається, є унікальні притаманні атрибути, які на поверхні його цілком підходять для використання в якості первинного ключа. Це врятує дизайнерів БД від створення виділеного первинного ключа, який не виконує жодних інших цілей. Однак насправді багато з цих "очевидних" первинних ключів є змінними. Ім'я людини може змінюватися (наприклад, вони одружуються), як і їх адреса, номер телефону тощо. Навіть щось на зразок посвідчення службовця може змінитися, якщо змінити формат посвідчення особи.

— Lèse majesté

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

— Марко Демайо

@Marco Аргумент UX полягає не в тому, що користувач вводить URL-адресу, а в тому, щоб дати користувачеві вказівку про те, про яку сторінку йде. Існує вагомий аргумент, щоб зовсім не використовувати ідентифікатор, але тоді ви стикаєтеся з технічними труднощами, шукаючи довгі рядки замість швидкого простого ідентифікатора.

— НезадоволенеЗакар

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

— НезадоволенеГотування

@lulala: Так, якщо ви 301 або встановите канонічне посилання, Google буде знати, щоб оновити їх індекс.

— Lèse majesté