komdir: во первых вы не озвучили причину переезда)
во вторых, если нет криминала, то:
проверьте регион нового домена, работайте с ним, как с новым доменом и не забывайте про старый.
Другими словами, работает стандартный режим склейки.
При учете всех показателей, позиции изменятся, но на насколько значительно зависит от тематики)
А как причина переезда может влияеть на алогоритма ранжирования? Роботу не все ли равно переезд был просто из-за нового более красивого имени или по какой то другой причине?
Региональной привязка, что у старого, что у нового домена : "не имеет региональной принадлежности". То что работать надо это понятно. Вопрос в другом, после склейки двух сайтов, если позиции сразу не встали на старые позиции, то можно не ждать у моря погоды, они уже не встанут? Или после склейки доменов восстановление позиций может занимать какое то время
UPDATE:
совсем забыл.
В $_GET и других сеперглобальных массивах уже декодированные данные храняться.
Код указанный выше - не стоит юзать:)
Так что просто применяйте $_GET['option']
urldecode($_GET['option']) вот так помогло, без urldecode получался код.
---------- Добавлено 13.03.2013 в 20:48 ----------
siv1987: В вашем первом варианте они не в нормальном явление, они экранированные. Их конечно можно декодировать и получить нормальное значение, но фактически это будут два разных адреса.
Не нормальное: %25D1%2582%25D0%25B5%25D1%2581%25D1%2582
Нормальное: %D1%82%D0%B5%D1%81%D1%82
строка: тест
хмм, а как экранирование убрать?
По большому счету все проблемы решение:
1) флаг NE - оставляет русские буквы в адресе
2) urldecode($_GET['option']); преобразует экранированные как я понял коды , в руские буквы.
Просто уже хочется до конца понять, а как экранированный код преобразовать к неэкранированный, то есть чтобы вместо %25D1%2582%25D0%25B5%25D1%2581%25D1%2582 был %D1%82%D0%B5%D1%81%D1%82
Кажется разобрался, огромное спасибо. Но в ходе решения данной проблемы, я задался вопросом. По идеи , как я понял эти шестнадцатиричные симолы нормальноя явление, теже поисковики понимают эти коды и сопостовляют им русские запросы... Отсюда вопрос, посредстмов php как можно преобразовать шестнадцетирчный код в сивольный?
iren K: вам нужно чтобы файл .htaccess был в кодировке UTF-8 без BOM
Что то непонятное происходит. Открываю htaccess меню кодировку на utf-8 сохраняю, заново открываю его и смотрю кодировка все равно старая стоит.. Прием если файл переименовать в какой то другой, то кодировка сохраняется, а вот в .htaccess нет.. Как такое может быть?
mrxmry: А CMS случайно не DLE 9.8 ? Просто я читал в нововведениях у 9.8 версии, что там какие то функции по поводу авторизации на поддоменах новые будут, как раз что-то из вашей оперы.
Joomla 1.5
---------- Добавлено 13.02.2013 в 02:21 ----------
Обнаружил еще один ньанс. Авторизация происходит через обращение к основному домену. Если же сделать чтобы авторизация происходила через поддомен, то тогда ситуация будет противоположная - чтобы оказаться авторизованным на основноме домене, надо вначале открыть поддомен.
То есть можно прийти к выводу, что через какой домен происходит авторизация, к тому домену и нужно обратиться, чтобы восстановить сессию на остальных доменах (поддоменах). Похоже на то, какому соседу ключ оставил, к тому нужно зайти чтобы его забрать)
1) http://clip2net.com/s/5BxQEh
2) http://help.yandex.ru/webmaster/?id=1108951
Да, согласно этим рекомендация я все и делал.
---------- Добавлено 21.08.2013 в 19:26 ----------
если вы все знаете, зачем спрашиваете?
:)
Так я спрашиваю про то, чего не знаю
---------- Добавлено 21.08.2013 в 19:28 ----------
Вы считаете это сроком? Подождите еще 1 месяц и посмотрите, что будет. Яндекс у нас медленный в отличии от Google..
А ну то есть, вы склоны считать, что даже если Яндекс уже домены склеил все равно может потребоваться какое то время на восстановление позиций?
молча))))))))
Может тогда еще и погода влияет?)
во первых вы не озвучили причину переезда)
во вторых, если нет криминала, то:
проверьте регион нового домена, работайте с ним, как с новым доменом и не забывайте про старый.
Другими словами, работает стандартный режим склейки.
При учете всех показателей, позиции изменятся, но на насколько значительно зависит от тематики)
А как причина переезда может влияеть на алогоритма ранжирования? Роботу не все ли равно переезд был просто из-за нового более красивого имени или по какой то другой причине?
Региональной привязка, что у старого, что у нового домена : "не имеет региональной принадлежности". То что работать надо это понятно. Вопрос в другом, после склейки двух сайтов, если позиции сразу не встали на старые позиции, то можно не ждать у моря погоды, они уже не встанут? Или после склейки доменов восстановление позиций может занимать какое то время
Огромне все спасибо, все тепреь понятно, все работает!
Option взят из примера в 1-ом посте.
UPDATE:
совсем забыл.
В $_GET и других сеперглобальных массивах уже декодированные данные храняться.
Код указанный выше - не стоит юзать:)
Так что просто применяйте $_GET['option']
urldecode($_GET['option']) вот так помогло, без urldecode получался код.
---------- Добавлено 13.03.2013 в 20:48 ----------
В вашем первом варианте они не в нормальном явление, они экранированные. Их конечно можно декодировать и получить нормальное значение, но фактически это будут два разных адреса.
Не нормальное: %25D1%2582%25D0%25B5%25D1%2581%25D1%2582
Нормальное: %D1%82%D0%B5%D1%81%D1%82
строка: тест
хмм, а как экранирование убрать?
По большому счету все проблемы решение:
1) флаг NE - оставляет русские буквы в адресе
2) urldecode($_GET['option']); преобразует экранированные как я понял коды , в руские буквы.
Просто уже хочется до конца понять, а как экранированный код преобразовать к неэкранированный, то есть чтобы вместо %25D1%2582%25D0%25B5%25D1%2581%25D1%2582 был %D1%82%D0%B5%D1%81%D1%82
Кажется разобрался, огромное спасибо. Но в ходе решения данной проблемы, я задался вопросом. По идеи , как я понял эти шестнадцатиричные симолы нормальноя явление, теже поисковики понимают эти коды и сопостовляют им русские запросы... Отсюда вопрос, посредстмов php как можно преобразовать шестнадцетирчный код в сивольный?
Попробуйте добавить флаг NE. Кодировка и переводы строк в данном случае не важны.
А куда этот флаг добавить? у меня сразу 500 ошибка вылетает.
Проверил, кодирока UTF-8 без BOM стоит, но это не решает проблему с редиректом русских букв.
---------- Добавлено 13.03.2013 в 18:13 ----------
Код такой..
RewriteCond %{HTTP_HOST} ^sub\.domain\.com$
RewriteCond %{REQUEST_URI} !^/dir/
RewriteRule ^(.*) /dir/$1 [L]
RewriteCond %{HTTP_HOST} ^www\.domain\.com$
RewriteRule ^dir/(.*) http://sub.domain.ru/$1 [R=301,L]
То есть я не прописываю кокрентно русские страницы.. захватываются все адреса, среди которых есть адреса с русскими буквами.
вам нужно чтобы файл .htaccess был в кодировке UTF-8 без BOM
Что то непонятное происходит. Открываю htaccess меню кодировку на utf-8 сохраняю, заново открываю его и смотрю кодировка все равно старая стоит.. Прием если файл переименовать в какой то другой, то кодировка сохраняется, а вот в .htaccess нет.. Как такое может быть?
А CMS случайно не DLE 9.8 ? Просто я читал в нововведениях у 9.8 версии, что там какие то функции по поводу авторизации на поддоменах новые будут, как раз что-то из вашей оперы.
Joomla 1.5
---------- Добавлено 13.02.2013 в 02:21 ----------
Обнаружил еще один ньанс. Авторизация происходит через обращение к основному домену. Если же сделать чтобы авторизация происходила через поддомен, то тогда ситуация будет противоположная - чтобы оказаться авторизованным на основноме домене, надо вначале открыть поддомен.
То есть можно прийти к выводу, что через какой домен происходит авторизация, к тому домену и нужно обратиться, чтобы восстановить сессию на остальных доменах (поддоменах). Похоже на то, какому соседу ключ оставил, к тому нужно зайти чтобы его забрать)