[Webliberty]

Здравствуйте! Сегодня я предлагаю анонс своей новой записи на Блоге свободного вебмастера и посвящена она очень интересному, на мой взгляд, свойству вордпресс с его динамическими страницами. Наверняка многие сменили динамику постоянными ссылками, но этого оказывается недостаточно — лишние страницы все равно появляются в поиске.

Избежать этого можно используя технологию Clean URL на WordPress, таким образом избавившись от некоторых динамических параметров.

[SamMan]

Здравствуйте! Сегодня я предлагаю анонс

1. Хмм... сегодня 27-е ноября? :))
2. Чем анонсируемая статья отличается от ЧПУ – Человеко-Понятный Урл?
3. Зачем вообще лезть в потенциально опасный .htaccess если для описываемой проблемы п.2 как бы решает?

[Webliberty]

SamMan, именно сегодня я предлагаю анонс. Ни единого сходства нет, конечно если вы читали, а не мельком просмотрели первые строки, в которых действительно есть упоминание про чпу. И как вы сказали п.2 НЕ решает. Если для вас .htaccess является чем-то опасным тогда можете забыть про него.

[SamMan]

В том-то и дело что читал и так понял суть анонсируемой статьи - избавиться от '?' в URL - не так, разве?
Вот, из нее:

Чистые ссылки (Clean URL) – это ссылки, которые не содержат в своем адресе элементов запроса к базе данных...

Т.е., в переводе на человеческий, не пытаются ничего тянуть GET-ом, и знаки вопроса не лепят. А тогда, снова, см. п.2 и зачем тут htaccess?? Либо вы не четко поставили цель/задачу для обсуждаемой статьи.

[Webliberty]

SamMan, давайте, приведите мне пример любой страницы, для примера возьму эту: _http://blogowed.ru/2012/01/prodvizhenie-statej/?replytocom=2195 пройдите по ней и откроется именно эта страница, с параметром на URL, а ведь ЧПУ у этого блога настроено!

А если использовать Clean URL, и перейти по этой же самой странице, то никаких параметров не будет в строке адреса, откроется нормальная страница _http://blogowed.ru/2012/01/prodvizhenie-statej/

Причем здесь чпу вообще?

Этот способ и не только для ЧПУ адресов можно использовать но и для системы по умолчанию, когда страница формируется таким образом: сайт.ру/?p=1 Именно для этого в исключениях стоит параметр p, s и т.д. Думайте, вникайте, прежде чем что-то доказывать.

[SamMan]

Ага, теперь суть проблемы ясна, и ясно что пытается пофиксить статья.

Хорошо, а альтернативный путь (первый по хронологии) решения того же самого (он, фактически, тоже есть в вашем блоге) - Robots.txt+"доводка напильником" в Google webmaster tool? Я сам не тестил, но, судя по множеству отзывов - вполне себе решение...

Собственно, теперь вопрос такой: зачем вы стали изобретать второй способ решенной ранее (по крайней мере мне так кажется) проблемы? Этот второй способ что - надежнее? стабильнее? проще? универсальнее? Собственно, вы и сами пишете:

Проблема была решена, но последствия продолжали одолевать блог. О чем я? Попробую пояснить…

Но мысль, к сожалению, не раскрываете... Т.е. вы нашли "прокол" в первом методе? Расскажите, если это не ноу-хау. :)

P.S. У самого на блоге дерево-комментарии, так что во мне вы имеете заинтересованную лично и благодарную аудиторию... :)

[Webliberty]

Я приводил скрин из метрики. Страницы сразу выпали из поиска и после второго метода, но они постоянно фигурировали в логах статистики в панелях вебмастеров, т.е. в гугле это постоянно увеличивающийся список запрещенных к индексации страниц, который пополнялся с каждым новым комментарием, в яндексе это число загруженных страниц (отличается от страниц в поиске) и так же оно увеличивается. А зачем создавать нагрузку на сервер, когда боты ходят по всякому хламу, вот и принял радикальное решение, убрал запрет на такие страницы в роботсе и все логи в стате пропали, как и не было таких страниц.

Если проводить параллель с другими движками, то такая функция присутствует на Друпал, она там встроенная, а вордпресс нельзя просто взять и установить, его постоянно нужно допиливать, приходится что-то придумывать.

[SamMan]

Спасибо, прочитал все вами сказанное и решил - применяю! В принципе все получилось, но есть одно... наблюдение - хочу поделиться. Эксперимент проводился в 2-х браузерах - IE и Chrome и "наблюдение" случается только во втором. В общем:

I. ДО исправления .htaccess по вашей статье - поведение обоих браузеров идентично.
a. "Базовая" страница имеет URL: http://www.mysite.ru/bigpost.html
b. Ссылка в "древо-комментарии" имеет URL: http://www.mysite.ru/bigpost.html?replytocom=100#ajaxformdiv (только не спрашивайте зачем там якорь - у меня очень кастомная форма комментариев, и в ней - он нужен, на этот якорь опирается джава-скрипт; впрочем это все не относится к вопросу правильного редиректа).
c. В обоих браузерах вбиваем в адресную строку адрес b, получаем реально страницу по адресу а, но в строке, разумеется, адрес b, как и ожидалось.

II. ПОСЛЕ исправления .htaccess по вашей статье
В IE: вбиваем b, получаем страницу адресу а и с этим же адресом а в адр. строке - отлично!
В Chrome: делаем тоже самое, получаем тоже самое, но адрес в строке http://www.mysite.ru/bigpost.html#ajaxformdiv. Т.е. "выкушен" только имя и значение GET-параметра, якорь остался. Но, повторю, в IE отбрасывается все что после '?' включая и его самого.

Что это? "Фича" Хрома или недоучет правил редиректа в .htaccess? Не надо еще что-то подправить там? Сам по себе 301 точно случается, проверил это HttpWatch, хотя и лишнее это было, все и так ясно было. Кстати, он четко показывает (в параметрах 301-го ответа) что

Redirect A redirect to http://www.mysite.ru/bigpost.html was issued by the server

Так что очень похоже на самодеятельность Хрома, но, на всякий, хочу посоветоваться и Ваше мнение услышать, спасибо заранее!

[Webliberty]

SamMan, эта особенность не только у хрома, но и у Firefox присутствует, скорее IE выбивается из правил. Якорь в ссылке не приводит к дублированию, а всего лишь указывает на местоположение на странице (очень часто можно встретить заблуждение, мол ссылка с тегом #more приводит к дублированию - это не правда), поэтому ничего страшного в этом нету, кроме того если сделать редирект с # - пострадает функциональность, т.к. этот символ участвует во встроенных функциях вордпресс.