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
Это позволяет указать плагину на то, какую страницу мы хотим достать из кеша, при этом не перенаправляя никуда пользователя (в адресной строке UTM-метки у пользователя останутся).
Чёт не долистали вы до конца настройки плагина. Там есть "Параметры отслеживания"
Параметры отслеживания, которые следует игнорировать при кешировании. Посетители из Facebook, Twitter и других источников вашего веб-сайта обычно переходят по URL-адресу с добавленными параметрами отслеживания. Этот параметр позволяет плагину игнорировать эти параметры и показывать уже кэшированную страницу. Любое фактическое отслеживание с помощью Google Analytics или другого кода на основе Javascript должно по-прежнему работать, поскольку URL-адрес страницы не изменяется.Вот к куче того, что есь и нужно добавить яндексовскую метку.
На DLE тоже, да прилетело