1) Со старой URL ставится 301 Redirect на новую URL для передачи веса и для перехода пользователя.
2) 301 лучше 302, 302 - временный, 301 - постоянный.
3) Если нет возможности использовать htaccess - используйте любой доступный вариант.
Если сайт например на PHP, то
header("HTTP/1.1 301 Moved Permanently"); header("Location: newURL);
вам в помощь.
Если это nginx, то у него есть свои правила, и для правильного их составления есть даже переводчики apache-nginx.
Как показывает практика - никто толком не знает, что может выстрелить, а что нет. У каждого свои секреты и шаманские заклинания. Единственное в чем все более-менее сходятся, это - закупка ссылочных-постовых. Так что пробовать, пробовать и пробовать, применяя эрудицию, смекалку и нестандартное мышление.
И еще, нет смысла ожидать хоть каких-то вменяемых результатов сразу, СЕО - долгая партия :)
Гугл в помощь, он подсказывает, что например тут:
http://4seo.biz/tools/31/
А так бы я свой скрипт написал :)
Топикстартер выше написал, что
- чекеры синтаксиса - ваш вариант.
На счет остального - я очень сомневаюсь, что вы найдете сервис, или скрипт, который может проверить ЛОГИКУ ваших правил. Не думаю, что это реально возможно. Он ведь не будет знать, что конкретно вы хотите в результате того или иного правила, кроме того, при определенных правилах htaccess может быть масса как вхождений, так и результатов.
Тут только ручками, правило за правилом анализировать, для чего оно и что делает. В большинстве случаев ничего сложного там нет.
Если нет такого модуля или готовой возможности:
1) Добавляем поле в таблице со статьями "translitname", например. В той таблице, где ID и Name статьи.
2) Скриптиком пробегаемся по таблице, выбирая имена статей, и добавляя в новосозданное поле транслитерацию заголовка статьи.
3) В код добавления/редактирования статей встраиваем участок, который сразу будет на будущее выполнять эту операцию.
4) В файле, отвечающем за обработку GET запроса в виде цифр, добавляем код, который смотрит в базу и по GET['id'] получает translitname. В случае успеха - редирект 301 на /post/translit_name, неуспеха - на главную, например.
5) В этом же файле добавляем, что если GET уже translitname - выводим статью.
Второй вариант - .htaccess проверять, что GET цифровой и кидать в специальный файлик редиректа, который выполнит туже операцию - переведет id в translitname и сделает редирект на нужную статью уже по имени.
Этапы создания:
1) В настройке зоны нового домена прописываем тот же IP, что и у старого домена.
2) На хостинге создаем папку и виртуальный хост, правильно указав название нового домена.
3) В папочку нового домена кладем index.html с простеньким содержанием "<html>Я тут</html>", например.
4) Идем по имени нового домена и лицезреем "Я тут".
Если не лицезреем или лицезреем не то - значит проблема с конфигурацией DNS или хостинга. Если лицезреем - делаем дамп старого сайта и заливаем. Дальнейшие проблемы, если есть - ищем в файлах сайта и его БД.
Суть пути - определить на каком из этапов приключилась сложность, на этапе DNS, хостинга или уже потом, на этапе редиректа в коде сайта.
PS: детальнее можно в личку, домены и хостинг посмотреть, скажу со своей стороны в чем сложность.
Можно было не указывать, он очень легко находится и без ссылки. yprazhneniya-bb - довольно уникальный ключ для поиска.
Очевидно были не полностью выполнены инструкции по обновлению, или не завершены. В частности не были выполнены SQL отвечающие за создание необходимых полей в вашей БД.
Еще как вариант - несостыковка определенных модулей старой и новых версий, если существуют значительные отличия. Или перезапись обновления поверх сайта с установленными дополнительными модулями или ручными правками. Например, был сайт, на нем были произведены существенные изменения, по которым накатились обновлением сверху, без их учета.
Upd
Посмотрел на ваш сайт, начните с проверки работы htaccess и ЧПУ, а потом смотрите откуда идет вызов непосредственно файла, который не могут найти боты. Точнее это даже не боты не могут найти, а ошибка генерируется на сервере при попытке обращения к несуществующему файлу/директории. Возможно в php коде есть попытка открыть или включить данные файлы для отображения, что и вызывает ошибку. Строчки лога не полные, если это ошибки php, обычно еще указывается строка и файл, из которой происходит вызов.
1. При заливке в базу данных на хостинг накатывать не всю БД, а только исправленный кусок в виде SQL запросов. Либо через phpmyadmin, например, либо прямым выполнением SQL на сервере. Зачем весь дамп для этого перезаливать? На момент исправлений в локальной копии вы же выполняете определенный запрос/запросы. Вот точно так же и на хостинге выполняется.
Пример:
Добавилось у вас дополнительное поле в таблице users, ну так и выполните на рабочей базе на хостинге "alter table add column"; перед этим конечно забэкапив базу на всякий случай перед изменениями.
2. Проблема несоответствия настроек хостинга и локальной машины. Приведите в полное соответствие, что бы не возникало таких проблем в принципе. В любом случае необходимо учитывать, что если, допустим, вы стали использовать новую библиотеку php, то перед накатыванием необходимо убедиться, что она и на хостинге уже установлена. Будет неплохо, если архитектура и главное - операционная система и модули/пакеты к системе были однотипны на тестовой-рабочей машине и основном хостинге. Если у вас на хостинге Centos установлен, то и тестовая локальная машина лучше что бы была такой же, с теми же версиями. Это будет сводить к минимуму возможные проблемы несовместимости. Потому как когда кодят на Windows, в каком-нить Eclipse, а потом все это переливают на Centos в чистую - ничего удивительного, что будут несостыковки.
3. Для контроля версий SVN/CVS вам в помощь.
