Странное поведение Googlebot

[@CAJAX]

Может вместо этих редиректов просто прописать canonical в хедере?

[@Robin_Bad]

rel=«canonical» тоже прописан, но это не помогает. к тому же, в любом случае, ответ HTTP имеет приоритет над любыми директивами в разметке, а Googlebot реагирует на него не вполне неадекватно, на мой взгляд.

[@CAJAX]

Очень странно. У меня сайт, в котором последний сегмент адреса может быть каким угодно, как правило текст из заголовка. В хедере <link rel=«canonical» href=«hxxp://site.com/ID/»/> выправляет все варианты в один, хотя, если верить гугланалитиксу, приходят по абсолтно разным ссылкам.

[@Robin_Bad]

я почти уверен, что это два разных и не связанных процесса — склейка дублей и обход сайта ботом. суть в том, что именно бот ведёт себя не так, как от него ожидаешь, чем создаёт повышенную нагрузку на сервер и генерирует ошибки, которых могло бы и не быть. а вопрос с дублями так или иначе решится, конечно. либо редиректами, либо через rel=«canonical», либо закрытием от индексации. кстати сказать, добавление вышеупомянутых символов в исключения позволило полностью избавиться от подобных ошибок.

[@Illorian]

Нууу....>_ _

[@prairie_dog]

Вы уже отправили баг-репорт?

[@Robin_Bad]

подскажите, куда его отправлять? искал — не нашёл

[@prairie_dog]

support.google.com/websearch/bin/static.py?hl=en&page=ts.cs&ts=1209905 — вот нашел такую ссылку, надеюсь, поможет.

[@prairie_dog]

Нет, не та ссылка, это всего лишь faq. Думаю, что через Google Webmaster можно отправить, но, к сожалению, его под рукой нет(

[@prairie_dog]

Видимо, вам на нужно сначала на форуме продуктов Google топик создать. Тут

[@Robin_Bad]

спасибо вам! создал там тему. самого теперь гложет любопытство, какая будет реакция (и будет ли вообще).

[@silentnuke]

не особо надеялся бы..) баги запостил по android'у еще в декабре, ноль реакции)

[@Robin_Bad]

да у меня тоже судя по активности на этом форуме складывается впечатление, что оно «ни о чём». ну, я свой гражданский долг выполнил, даже несмотря на явное желание Гугла максимально дистанцироваться от любых попыток пользователей сообщить им о проблеме :)

[@AgaFonOff]

Даже если это и не так, на деле высё выглядит очень уж на то похоже: и на нежелание, и на попытку… Я просто как ребенок радовался, когда в новых G-продуктах видел кнопку «сообщить о проблеме» :)

[@SerCe]

Прочитал GWT, подумал Google Web Toolkit и только потом понял, что Google Webmaster Tools

[@tenshi]

«Всё правильно, одиночные кавычки согласно RFC 3986 кодируется как %27.»

не правильно. читаем приложение А, где собран формальный синтаксис:

path = path-abempty; begins with "/" or is empty
/ path-absolute; begins with "/" but not "//"
/ path-noscheme; begins with a non-colon segment
/ path-rootless; begins with a segment
/ path-empty; zero characters

path-abempty = *( "/" segment )
path-absolute = "/" [ segment-nz *( "/" segment ) ]
path-noscheme = segment-nz-nc *( "/" segment )
path-rootless = segment-nz *( "/" segment )
path-empty = 0

segment = *pchar
segment-nz = 1*pchar
segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
; non-zero-length segment without any colon ":"

pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
pct-encoded = "%" HEXDIG HEXDIG

unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="

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

поэтому лучше сравнивать не сырые uri, а нормализованные — тогда никаких петель не будет. «склейщик страниц» тоже наверно не дурак и производит нормализацию ссылок.

[@Robin_Bad]

я вынужден сравнивать именно так (грубый пример на коленке):

$_SERVER['REQUEST_URI'] = "/blog/tag/guns'n'roses/";
if(($uri = urlencode(urldecode($_SERVER['REQUEST_URI']))) != $_SERVER['REQUEST_URI'])
{
	header('Location: ' . $uri, true, 301);
	die;
}

потому что в противном случае в том же GWT будет сообщение, что страницы "/blog/tag/guns'n'roses/" и "/blog/tag/guns%27n%27roses/" имеют одинаковые title и description (будут они в дальнейшем склеены или нет — уже другой вопрос, мы ведь сейчас не о нём).

опять же, в спецификации функции urlencode() написано, что она соответствует RFC 3986 за одним исключением: «Это отличается от » RFC 3986 кодирования (см. rawurlencode() ) тем, что, по историческим соображениям, пробелы кодируются как знак „плюс“ (+)». т.е. на приведённом мной примере они работают совершенно идентично c rawurlencode(), которая уж точно согласно документации: "Кодирование строки осуществляется согласно » RFC 3986."

но и дело даже не в этом. если бот получает «Location: /blog/tag/guns%27n%27roses/», то к чему самодеятельность — зачем он идёт на "/blog/tag/guns'n'roses/"? для меня это равносильно, если бы он пошёл, например, на "/blog/tag/metallica/" :)

[@Woodroof]

Так, может, проблема в том, что вы кодируете то, что не нужно? Оставьте в качестве референсной страницу со слэшами, и проблема исчезнет.

[@Robin_Bad]

проблема лично мной уже решена, как я писал выше, тем, что ряд спецсимволов (слэш тут не при чём, кстати) добавлен в набор «исключений». просто описанное поведение бота неочевидно и не соответствует ожидаемому, отчего у кого-то могут возникнуть проблемы.

[@Woodroof]

слешами апострофами, конечно

[@InteractiveTechnology]

Да ладно, может он просто ищет sql-injection, это же гугл :)