Длина URL

Смысл в том, что страница содержащая в своём тексте все слова из запроса будет в общем случае более релевантной, чем те, которые не содержат или содержат не полный набор ключевых слов запроса.

В данном случае имеется ввиду, что URL документа, содержащий название товара будет добавлять дополнительный вес релевантности документа при запросе по названию товара. И наоборот, если в URL-е документа не будет использоваться название товара, то оно не будет добавлять доп. вес для релевантности страницы при запросе по названию товара.

Дубли адресов при полном совпадении названия товара/объекта и т.д.

Вопрос о простоте работы с базой весьма спорный. ЧПУ есть ЧПУ.

Но если в урлах действительно ID (настоящие, а не искусственные), то это может стать большой проблемой при переносе контента. Не говоря уже про смену движка.

А делается (делалось так во всяком случае) тк. гугл требовал цифер в урле.. для гуглоньюс что ли, не помню уже, давно это было. Много одно время вопросов было - как добавить эти цифры в урл.

АПД. Да, точно, память не подвела - оно. :) После чего стало много подобных запросов.

Откровенно говоря, не вижу проблемы, если изначально сделано правильно. У каждой карточки товара - свой алиас, сформированный из названия документа (названия товара). ID - хоть реальный (по товарной номенклатуре), хоть виртуальный (может быть порядковый) - в отдельной ячейке БД. Рабочий URL формируется путём сложения алиаса и нужного ID (может в любой форматной последовательности, в том числе и заданной админом, если сильно нужно). При выполнении миграции здесь не должно быть проблем, когда данные по БД разделенные.

Вот потому что ты не технарь - поэтому не знаешь что такое реальный и потому и не видишь проблемы.

Ок. объясню. Реальный ID - это ID записи в базе данных.  (а "по товарной номенклатуре" называется SCU) Это уникальное значение в пределах как минимум одной таблицы, а то и всей базы.

Как правило эти ID движок сам назначает, автоматически. При импорте контента (не путать с импортом дампа базы!) эти ID в 99,9% случаев будут изменены.

А вот если применяются искусственные ID (доп произвольные  поле данных) - тогда проблем намного меньше. Но всё равно, хоть и небольшие, но лишние телодвижения.

Мы и говорим про базу данных. Есть две области данных. Одна группа - ID движка, другая группа - SCU. Мы можем оперировать ими как угодно, хоть раздельно, хоть сливать с другими данными. Вопрос только в том, что конкретно надо сделать.

Это понятно, в данном случае ID-шники - это будут порядковые номера, а уникальные, будь-то SCU или как угодно названные (хоть отдельно вебмастером забитые через админку) - это отдельные поля в таблицe БД.

Основа - это всё равно алиас документа, хочешь добавляй к нему свой ID-шник, хочешь добавляй SCU - это вопрос только того, как будет сформулирована задача. Для нормального программиста здесь нет проблемы, 

в том числе и разобрать регуляркой рабочий URL, вычленить алиас (если он там есть), вычленить ID или SCU (если он там есть), занести новые записи в нужные поля БД, сопоставить и получить рабочий результат.

Проводил такие задачи десятки раз, конечно не сам, а через ТЗ программисту, но здесь решительно нет ничего сложного, для тех программистов, которые конечно умеют это делать.

Причём тут Гугл.Новости? TC приводит пример товарных URL-ов.

Володь, это уж как запрограммировано :) Я встречал варианты, когда ввод дублированного названия тупо вываливался по ошибке :)

А так, да, базово на дублирующую запись - цифру с номeром копии, как при сохранении в ОС.