How to become an author
Search
Write a publication
Pull to refresh

Comments 21

Может вместо этих редиректов просто прописать canonical в хедере?
Total votes 2: ↑2 and ↓0+2
rel=«canonical» тоже прописан, но это не помогает. к тому же, в любом случае, ответ HTTP имеет приоритет над любыми директивами в разметке, а Googlebot реагирует на него не вполне неадекватно, на мой взгляд.
Total votes 1: ↑1 and ↓0+1
Очень странно. У меня сайт, в котором последний сегмент адреса может быть каким угодно, как правило текст из заголовка. В хедере <link rel=«canonical» href=«hxxp://site.com/ID/»/> выправляет все варианты в один, хотя, если верить гугланалитиксу, приходят по абсолтно разным ссылкам.
Total votes 1: ↑1 and ↓0+1
я почти уверен, что это два разных и не связанных процесса — склейка дублей и обход сайта ботом. суть в том, что именно бот ведёт себя не так, как от него ожидаешь, чем создаёт повышенную нагрузку на сервер и генерирует ошибки, которых могло бы и не быть. а вопрос с дублями так или иначе решится, конечно. либо редиректами, либо через rel=«canonical», либо закрытием от индексации. кстати сказать, добавление вышеупомянутых символов в исключения позволило полностью избавиться от подобных ошибок.
Total votes 2: ↑2 and ↓0+2
подскажите, куда его отправлять? искал — не нашёл
Total votes 2: ↑2 and ↓0+2
Нет, не та ссылка, это всего лишь faq. Думаю, что через Google Webmaster можно отправить, но, к сожалению, его под рукой нет(
This comment wasn’t rated yet0
Видимо, вам на нужно сначала на форуме продуктов Google топик создать. Тут
This comment wasn’t rated yet0
спасибо вам! создал там тему. самого теперь гложет любопытство, какая будет реакция (и будет ли вообще).
Total votes 5: ↑5 and ↓0+5
не особо надеялся бы..) баги запостил по android'у еще в декабре, ноль реакции)
This comment wasn’t rated yet0
да у меня тоже судя по активности на этом форуме складывается впечатление, что оно «ни о чём». ну, я свой гражданский долг выполнил, даже несмотря на явное желание Гугла максимально дистанцироваться от любых попыток пользователей сообщить им о проблеме :)
Total votes 1: ↑1 and ↓0+1
Даже если это и не так, на деле высё выглядит очень уж на то похоже: и на нежелание, и на попытку… Я просто как ребенок радовался, когда в новых G-продуктах видел кнопку «сообщить о проблеме» :)
This comment wasn’t rated yet0
Прочитал GWT, подумал Google Web Toolkit и только потом понял, что Google Webmaster Tools
Total votes 5: ↑5 and ↓0+5
«Всё правильно, одиночные кавычки согласно 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, а нормализованные — тогда никаких петель не будет. «склейщик страниц» тоже наверно не дурак и производит нормализацию ссылок.
Total votes 1: ↑1 and ↓0+1
я вынужден сравнивать именно так (грубый пример на коленке):
$_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/" :)
Total votes 2: ↑2 and ↓0+2
Так, может, проблема в том, что вы кодируете то, что не нужно? Оставьте в качестве референсной страницу со слэшами, и проблема исчезнет.
This comment wasn’t rated yet0
проблема лично мной уже решена, как я писал выше, тем, что ряд спецсимволов (слэш тут не при чём, кстати) добавлен в набор «исключений». просто описанное поведение бота неочевидно и не соответствует ожидаемому, отчего у кого-то могут возникнуть проблемы.
This comment wasn’t rated yet0
слешами апострофами, конечно
This comment wasn’t rated yet0
Sign up to leave a comment.

Articles

Show the best of all time

Your account

Sections

Information

Services

Support
© 2006–2024, Habr