Влияние Cloudflare на ранжирование в Яндексе

Как может цдн влиять на ранж? Никак ( если работает и не блочит ботов) 

Не знаю на счёт клауда, но вот с Тильдой у меня давным давно была история. Там в общем стоит у них какая-то защита от дудоса, и я однажды заметил, что иногда она срабатывает, когда на сайт приходит бот Яндекса. Если нет такой защиты истеричной у клауда — по идее никак не должно влиять. Но вообще, чем быстрее ты отдаёшь контент, тем лучше, а CDN это лишнее звено, так или иначе, и у клауда вроде нет серваков в России, чтобы оттуда контент отдавать. В общем, там не такие большие задержки, чтобы это прям повлияло.

Экспериментов не проводил. НО для яндекс бота сайт работает чуть медленнее, чем мог бы работать. Хотя если посмотреть на тормозные сайты в топах, это не существенно.

Там ДдосГард стоит. Настроено все грамотно, от ддоса держит хорошо. Косяки если вылазят, то достаточно редко. В декабре крайний раз было, когда некоторые сайты error 410 стали выдавать.

Это потому что шум поднялся, мне даже спустя несколько лет в ВК писали люди с этой проблемой, спрашивали, что делать. Может быть сейчас поправили. А тогда у меня при суточном трафике 8.000 — раз в несколько дней страницы пачками вылетали из индекса, причём, это были само собой самые трафиковые страницы. Но, если сайт не под трафик из ПС, наверное это норм. Я не выдержал натиска и пошёл делать сайты на WP.

Вот 2 сайта одних и тех же владельцев. DTF с клаудом, VC без (на паузе стоит).
На скриншоте показания рандомные, результат первого запроса. В рандомном результате без Cloudflare отклик яндекс боту получился чуть быстрее.

Усложняем эксперимент, берем уже 10 результатов. И вот здесь, на массиве данных, DTF проигрывает всухую.
Так как некоторые запросы идут через экзотические локации. Например вот это - через Вьетнам.

Итого VC без клауда - среднее 272 мс, DTF с клаудом 1034 мс. В 3 раза хуже.

А теперь возвращаемся к вопросу того, что каждый лузер (супер крутой админ, настраивающий сервак с закрытыми глазами - тоже лузер с нереализованными понтами, если он влазит настраивать клауд) считает себя как минимум богом, если он разобрался в том, как сменить NS записи у регистратора и скачать с VC пару детских настроек для WAF.

Вот отклик еще по одному сайту, с Cloudflare. Среднее по результатам 10 измерений - 213 мс. Что лучше, чем у VC без Cloudflare.

Также нужно учитывать, что настройка защиты должна быть комплексная. Которая еще учитывает внешние запросы сайта и необходимую оптимизацию, исключение лишних запросов к сторонним сайтам и сервисам там, где это возможно. Нужно не только клауд подключать, а еще и свой собственный сайт и сервер оптимизировать.

Понятно, что появление дополнительной прокладки между браузером и сервером - удлиняет запрос. Вопрос в том, на сколько. И что вы получаете в обмен на это удлинение.

Вывод по результатам эксперимента такой: понты лучше отложить в сторону.
Каждый должен заниматься тем, в чем он разбирается. Профессионал в чем-то одном, который лезет настраивать что-то в соседнюю тему - нарукожопит. И будет потом сказки рассказывать, как он по инструкции все настроил, после чего все испортилось, клауд плохой.
Не клауд плохой, а руки у кое-кого не с того места растут.

Очевидно же, что любая дополнительная прокладка между сайтом и точкой откуда делается запросом добавляет задержки. Другое дело, из-за чего эти задержки и как они влияют на что-либо. Например, показанная на скриншоте задержка может вызываться каким-либо внешним скриптом, шрифтом, картинкой и т.п. Задержки могут возникать из-за загрузки каналов между двумя точками или на одной из точек в маршруте. Причин может быть множество, но сомнительно, что это связано именно с CloudFlare. 

Без клауда. Заменил картинку, на старой с 301 редиректом страница.

Сервер тот же, но через клауд