С плагинами кэширования можно прощаться, благодаря нововведению Яндекса!!!

Просто не будет кэшироваться страница с параметрами, из кэша страница без параметров отдаваться не будет.

Всем спасибо за советы.

Если решусь, удалю все сайты с хостинга.
Честно говоря, устал. Буду искать "более прозрачные" ниши...

Всем добра!

https://habr.com/ru/articles/573750/

Проблемы WP Super Cache

Единственная (но критичная) проблема WP Super Cache заключается в том, что он не умеет вычленять из URL необходимые GET-параметры, и все страницы с UTM-метками и прочими аналитическими параметрами считает за уникальные.

Разработчики плагина как будто бы знали о такой проблеме, потому что предусмотрели настройку «Не кешировать страницы с параметрами GET (?x=y в конце URL)». Тем не менее, она ничего не даёт, кроме экономии места на диске, потому что кеш не будет создаваться для страниц с GET-параметрами.

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

Ничего умнее я не смог придумать, как добавить в файл wp-content/plugins/wp-super-cache/wp-cache-phase1.php следующий код:

после строчки $wp_cache_request_uri

function removeGetParameter($url, $varname) {
        return preg_replace('#\\?$#', '', preg_replace('/([?&])'.$varname.'=[^&]+(&|$)/','$1',$url));
}
$wp_cache_request_uri = removeGetParameter($wp_cache_request_uri, "utm_source");
$wp_cache_request_uri = removeGetParameter($wp_cache_request_uri, "utm_medium");
$wp_cache_request_uri = removeGetParameter($wp_cache_request_uri, "utm_campaign");
$wp_cache_request_uri = removeGetParameter($wp_cache_request_uri, "utm_content");
$wp_cache_request_uri = removeGetParameter($wp_cache_request_uri, "utm_term");
$wp_cache_request_uri = removeGetParameter($wp_cache_request_uri, "gclid");
$wp_cache_request_uri = removeGetParameter($wp_cache_request_uri, "yclid");

Это позволяет указать плагину на то, какую страницу мы хотим достать из кеша, при этом не перенаправляя никуда пользователя (в адресной строке UTM-метки у пользователя останутся).

Он их потом убирает, если 404 выдается ошибка... Было такое, точно не помню, но с год назад.

Не стоит, разумеется.
Всё дело в том, что Яндекс данным нововведением создал Вебмастерам лишние проблемы.

Если в плагине super-cache отключить кэширование страниц с get параметрами, то они кэшироваться не будут. Вместо них не будет отдаваться из кэша никакая сохранённая копия. 

А это значит, что кэш, фактически, будет работать только для внутренних переходов по сайту.

RewriteCond %{QUERY_STRING} ^ysclid=(.*)$

RewriteRule ^(.*)$ $1?ysclid=$1 [R=301,L]

А в Метрике или в Вебмастере переходы с Яндекса не станут прямыми заходами?

Разве эти  ysclid не только в ПК-выдаче работают? У меня на МОБ никаких  ysclid нету, только при переходе на ПК. А так как 85% трафа с МОБ, то и пусть. Главное, что на МОБ кеш отдается, на ПК и так инет везде нормальный.

Нет, метрика как было, так и показывает из поиска
Вебмастер аналогично
Ничего не меняется на включение правила 301

Это введено для их внутренней аналитики, когда один отдел, не ведает, что творит другой))

Переходы  становятся прямыми заходами, только в одном случае - fraime траф, если закрыть фрейм
К примеру толокер заходит на сайт по фрейму, закрываем fraime - фиксируется прямой заход

А Вы как ибавились от  ysclid? 301 редирект используете или отключили этот "эксперимент"?

Кстати у меня все нормально. В настройках плагина и так было все четко: