Сильно ли нагружает такой поиск по таблице БД?

Боже какие Яндекс программисты ЖОПОРУКИЕ... это же надо было додуматься... А полного косяка мы не знаем... может быть там не только запятая, а ещё тире например было или нижные подчёркивание.

Я правильно понимаю, мне в базе надо вместо урл -20,5x20,5 прописать, например, новый урл -20-5x20-5, а на обработчике проверять, если запросили урл -20,5x20,5 , то открывать урл -20-5x20-5

Что то я запутался.

Или мне надо в базе прописать, допустим ещё один столбец (столбец соответствия), где урлу -20,5x20,5 будет соответствовать -20?5&5x20 и если запросили -20,5x20,5 ТО ОТКРЫВАТь -20?5&5x20

не пойму как лучше сделать.

Верно поняли.

Спасибо, Леонид. Точно, так и сделаю.

А адреса страниц для бота сменятся со временем или так и будут с запятыми в поисковой базе? Или теперь черт ногу сломит понять что к чему..

ps Кстати. Тут открывается новая проблема. В Гугле то все в порядке. Для Гугла страницы тупо переедут. Потеряем позиции.

Верно. Или как я и говорил, просто ждать.

Ребят, вообщем Яндекс дал четко понять, что урлы

14,9x100 видит как -14?9x100

-35x100,8 видит как -35x100?8

-49,6x49,6 видит как -49?6&6x49

Что можно прописать в .htaccess чтобы для раздела laminat/ действовали правила

редиректа с

-14?9x100 на -14-9x100

-35x100?8 на -35x100-8

-49?6&6x49 на -49-6x49-6

или даже так

-14,9x100 на -14-9x100

-35x100,8 на -35x100-8

-49,6&49,6 на -49-6x49-6

Ой ли?

то же самое описал и я. Только не в htaccess, а в коде. И не 6000 правил писать, а один временный костыль.

Смысл всех махинаций - плавная смена url, без потерь в поисковиках и потерянных всвязи с этим страниц. Решение за тобой.

VHS, я просто не все понял.

Смотрите, в обработчике пропишу правило

если запросили ...-14,9x100 тогда открываем урл ...-14-9x100

если запросили ...-35x100,8 тогда открываем урл ...-35x100-8

если запросили ...-49,6x49,6 тогда открываем урл ...-49-6x49-6

но в БД таблице мне придется заменить урлы 14,9x100 на 14-9x100 и т.д. соответственно. Что происходит.

Юзеры переходят теперь в новые документы. Роботы ПС тоже. Старые урлы ни для Гугла ни для Яндекса уже не работают.

Еще раз поясню.

1 - Прорабатываем "канонический" урл, т.е. тот, который будет впоследствии верным. Самый простой вариант - просто убрать запятые, возможно заменить на точки.

2 - При запросе из базы приводить командой REPLACE текущие урлы к "каноническим". Входящие урлы запроса страниц преобразовывать так же для правильного поиска. Можно конечно сразу заменить урлы в базе. Но я бы не стал торопиться. Не забываем, что в Яше уже сидят урлы с "?" вместо ","

3 - После того, как выяснили, какая страница запрашивается - проверяем реальный урл. Если он не "канонический" - редиректим 301 на "канонический". Потерь позиций и документов в этом случае не будет. Если Урл запрашиваемой страницы равен "каноническому" - все ок, выдаем страницу.

Просто нет смысла писать обработчик на каждый урл - преобразуйте все по маске. А 301 редирект переведет все урлы под одно правило и для Г и для Я без потерь страниц.

Вот скажем так выдержка Г-кода из одного ИМ. Там урлы страниц формируются транслитерализацией названия товара. Названия корректируются постоянно, но ничего не выпадает. Правда там соответствие по айди.

$rightUrl = url2product($unit['cat_id'],$site['category']).$id."-".str2url($unit['name']).".html";

if($_REQUEST['str'] != $rightUrl){

header("HTTP/1.1 301 Moved Permanently");

header("location: /".$rightUrl);

exit();

}

На точки самый простой, но боюсь теперь на них менять.

---------- Post added 30-10-2014 at 13:23 ----------

Нет их нет, они 404 для Яши. Всего урлов с запятыми 2100, 1900 урлов уже выпали, так как отдали яндексу 404.