Давай я попробую ещё раз.
Если в адресах не используется ID (реальный ID), то перенос контента не взывает никаких дополнительных проблем/работ.
Если это они есть, то в случае пересвоения ID (что происходит в подавляющем большинстве движков) придётся писать немало костылей - начиная от смены правил ЧПУ, переходя от реального ID к искусственному. В ином случае - писать кучу 301. Но это может быть вообще невозможно. И дело не в объёме, а.. догадаешься почему или объяснить? ;)
Ну, вот и давай на конкретном примере, чтобы мы говорили об одном и том же. А то ты описываешь ситуацию со своего угла зрения, как будто в этой абсолютно расхожей задаче есть какая-то особенная сложность.
Есть входные данные www.site.ru/krovati/krovat-anjelika-id1486
Товар "Кровать Анжелика", ID-1486, категория - Кровати.
Категория вводится структурно, вложенность товара в категорию - понятно.
Далее, если себе гипотетически представить, что исходных ID в БД нет, а есть просто запись целевого рабочего url-а, то очевидно URL последовательность разбирается в логике до id - название товара, транслитом, где "-" замена пробела, а цифровая последовательность после id без пробела - номер ID. Фактическое соответствие по факту заданной строки между товаром и ID последовательностью есть - это связка заносится в БД.
Далее точно также, на новом сайте восстановить данный адрес не составляет труда (при условии совпадающей транслитерации) без всяких там 301-х редиректов. Новые ID сгенерированные CMS-ой в URL-е не выводить, а выводить те, что мы спарсили из исходной строчки (тогда это уже даже не ID, а просто параметр в строке URL-а). Так чего ж там такого особенного-то?
Если мы говорим о каком-то начинающем вебмастере, который приглядел новый движок и хочет c одной CMS платформы перевести свой товарный саттелит на другую - здесь у него могут возникнут вполне конкретные проблемы, которые он может и не решить без посторонней помощи. Но если это живой бизнес и нанятый опытный программист, то эта задача из разряда начального уровня - спарсить, разобрать, занести нужные данные в таблицы БД, сформировать новые URL-ы и далее для контроля - сравнить перечень URL-ов старого сайта с новым. При точном построчном совпадении задача выполнена.
:) Поэтому я и сказал, что Гугл.Ньюс нам не нужен, у нас другой случай. Изначально вообще речь была про необходимость сокращения URL-а, на что в первых же комментариях я дал ответ.
Сейчас там нет таких проблем, да и SEF компонентов великое множество.
Ok. Я бы сказал - доп. задачей. Любые направленные рабочие действия - это и есть набор задач. Но каких-то отличительных проблем здесь я действительно не вижу.
Проблемой может быть и то, что программист может внезапно заболеть и не уложиться в дедлайн.
Так там не про ранжирование, там про датировку материалов в учете Гугл.Новостей.
У современных общепринятых CMS таких проблем действительно уже давно нет, но мне наверное везет частенько сотрудничать с командами, где сайты на самописных CMS и там бывает всякое :)
Во-первых, не мне. Во-вторых, нет понятия "крохи", есть понятие - финансовая целесообразность и корпоративные интересы. Если крупный игрок не видит финансовых интересов, то он и не заполняет нишу, а кто сколько в данной нише заработает, это уже дело десятое.
Володь, это уж как запрограммировано :) Я встречал варианты, когда ввод дублированного названия тупо вываливался по ошибке :)
А так, да, базово на дублирующую запись - цифру с номeром копии, как при сохранении в ОС.
Причём тут Гугл.Новости? TC приводит пример товарных URL-ов.
Мы и говорим про базу данных. Есть две области данных. Одна группа - ID движка, другая группа - SCU. Мы можем оперировать ими как угодно, хоть раздельно, хоть сливать с другими данными. Вопрос только в том, что конкретно надо сделать.
Это понятно, в данном случае ID-шники - это будут порядковые номера, а уникальные, будь-то SCU или как угодно названные (хоть отдельно вебмастером забитые через админку) - это отдельные поля в таблицe БД.
Основа - это всё равно алиас документа, хочешь добавляй к нему свой ID-шник, хочешь добавляй SCU - это вопрос только того, как будет сформулирована задача. Для нормального программиста здесь нет проблемы,
в том числе и разобрать регуляркой рабочий URL, вычленить алиас (если он там есть), вычленить ID или SCU (если он там есть), занести новые записи в нужные поля БД, сопоставить и получить рабочий результат.
Проводил такие задачи десятки раз, конечно не сам, а через ТЗ программисту, но здесь решительно нет ничего сложного, для тех программистов, которые конечно умеют это делать.
Откровенно говоря, не вижу проблемы, если изначально сделано правильно. У каждой карточки товара - свой алиас, сформированный из названия документа (названия товара). ID - хоть реальный (по товарной номенклатуре), хоть виртуальный (может быть порядковый) - в отдельной ячейке БД. Рабочий URL формируется путём сложения алиаса и нужного ID (может в любой форматной последовательности, в том числе и заданной админом, если сильно нужно). При выполнении миграции здесь не должно быть проблем, когда данные по БД разделенные.
спасибо добрый человек. Значит санкций к тому, кто занимается продвижением, ровно как и к самим сайтам предъявлять не за что.
Пожалуйста :) Был и штатным сотрудником студии, и её главной, был и остаюсь частным специалистом - в моём рабочем профиле десятки сайтов, нередко с пересекающейся тематикой.
Это нормально, не волнуйтесь :)
