В JournalX бесконечный скролл удобен для ленты, но не всегда подходит для всех разделов сайта. На новостных или тематических архивах он может мешать аналитике, ухудшать поведение пагинации и создавать лишнюю нагрузку на фронтенд. Если нужно оставить бесконечную подгрузку только там, где она реально полезна, а в остальных местах вернуть обычную пагинацию, это лучше делать точечно, а не отключать функцию глобально.
Когда бесконечный скролл лучше убрать
Обычно проблема проявляется не сразу. Сайт выглядит нормально, но в отчётах растёт глубина просмотра без понятной структуры, пользователи не доходят до нижних блоков, а поисковому роботу сложнее предсказуемо обходить архивы. Ещё один частый сценарий — на части рубрик нужен классический список страниц, потому что там важны ссылки на конкретные страницы архива, а не непрерывная лента.
Если у вас в JournalX есть разделы с разной логикой потребления контента, не стоит держать один и тот же способ навигации везде. Для новостей, подборок и длинных лент бесконечный скролл может быть уместен. Для архивов с высокой ценностью пагинации — нет.
Диагностика: где именно ломается поведение
Сначала проверьте, как именно сейчас работает архив. Важно понять, это настройка темы, кастомизация в дочерней теме или поведение, добавленное плагином. Если отключить не тот слой, можно получить дублирование кнопок «Ещё» и обычной пагинации, либо наоборот — пустой низ страницы без подгрузки.
Что проверить в первую очередь
- какие архивы используют бесконечный скролл: главная лента, рубрики, метки, авторы;
- есть ли отдельные шаблоны для рубрик в дочерней теме;
- не подключён ли плагин, который тоже вмешивается в пагинацию;
- не завязан ли скролл на JavaScript-события, которые ломаются после оптимизации скриптов;
- как ведёт себя страница при отключённом JS в браузере.
Если при отключённом JavaScript список записей перестаёт подгружаться, значит, вам нужен запасной вариант навигации: обычная пагинация должна оставаться в HTML, а бесконечный скролл — быть только надстройкой.
Как отключить бесконечный скролл только для нужных архивов
Самый надёжный путь — не править файлы родительской темы, а добавить условную логику в дочернюю тему или в небольшой mu-plugin. Тогда обновление JournalX не затрёт изменения.
Если в теме есть фильтр или настройка, которая отвечает за тип навигации, используйте её. Но если отдельного переключателя нет, можно убрать скрипт или изменить шаблон вывода для конкретных архивов через условные теги WordPress.
Вариант через условную загрузку скрипта
Ниже пример, когда бесконечный скролл подключается отдельным скриптом, а на выбранных рубриках мы его не грузим. Название handle у скрипта нужно взять из кода темы или через просмотр зарегистрированных скриптов в консоли/дебаге. Пример ниже показывает сам принцип:
add_action('wp_enqueue_scripts', function () {
if (is_admin()) {
return;
}
// Не отключаем на главной ленте, но убираем на конкретных рубриках.
if (is_category(array('news', 'reviews', 'guides'))) {
wp_dequeue_script('journalx-infinite-scroll');
wp_deregister_script('journalx-infinite-scroll');
}
}, 100);Этот подход работает, если бесконечный скролл действительно завязан на отдельный скрипт. Если же логика встроена в общий bundle, деактивация по handle не сработает, и тогда нужно идти через шаблон или фильтр темы.
Вариант через шаблон архива
Если в JournalX для рубрик используется отдельный файл шаблона, проще вернуть обычную пагинацию прямо в разметке. Внизу архива должен быть стандартный вывод страниц, а не контейнер для подгрузки следующего блока.
<nav class="pagination" aria-label="Навигация по записям">
<?php
echo paginate_links(array(
'prev_text' => '« Назад',
'next_text' => 'Вперёд »',
));
?>
</nav>Если тема уже выводит пагинацию через the_posts_pagination(), не дублируйте её вручную. Сначала уберите блок бесконечной подгрузки, потом проверьте, не осталась ли старая кнопка «Загрузить ещё» в DOM.
Если нужен гибрид: скролл только на части сайта
На практике часто нужен компромисс: на главной и в «лёгких» рубриках — бесконечный скролл, в SEO-значимых архивах — обычная пагинация. Это нормальная схема, если она не ломает канонические URL и не создаёт дубли.
| Подход | Когда подходит | Минус |
|---|---|---|
| Отключить скрипт | Бесконечный скролл вынесен отдельным JS | Не сработает, если логика встроена в общий файл |
| Правка шаблона | Нужно точечно изменить архивы | Требует дочерней темы и аккуратного обновления |
| Фильтр/настройка темы | В JournalX есть штатный переключатель | Ограничен возможностями темы |
Если в проекте уже используется плагин для чистки дублей и SEO-настроек, например Clearfy Pro, проверьте, не конфликтует ли он с кастомной пагинацией и canonical на архивных страницах. Для таких задач полезно держать логику навигации и SEO-мета отдельно, а не смешивать в одном месте.
Проверка результата после внедрения
После изменений не ограничивайтесь визуальной проверкой. Нужно убедиться, что архивы действительно ведут себя по-разному там, где вы этого хотели.
Чек-лист проверки
- на нужной рубрике бесконечный скролл не подгружается;
- пагинация видна и кликабельна;
- URL страниц архива меняется корректно:
/page/2/,/page/3/и т.д.; - в консоли браузера нет ошибок JavaScript;
- на мобильных устройствах нижняя часть архива не «залипает»;
- поиск и фильтры, если они есть, продолжают работать.
Дополнительно откройте исходный код страницы и проверьте, что нет двух одинаковых блоков навигации. Если видите и бесконечный скролл, и обычную пагинацию одновременно, значит, отключение прошло не полностью.
Частые ошибки и как их исправить
Скрипт отключили, но подгрузка осталась
Это значит, что бесконечный скролл инициализируется не отдельным файлом, а частью общего JS. В таком случае ищите не только wp_enqueue_script(), но и inline-инициализацию, которая может висеть в шаблоне или в настройках темы.
Пагинация пропала вместе со скроллом
Так бывает, если в шаблоне был только контейнер для подгрузки, а обычная навигация не выводилась вообще. Решение простое: вернуть стандартный блок пагинации WordPress и проверить, что запрос архива не ограничен кастомным query без параметра paged.
На части рубрик всё сломалось после оптимизации
Если вы объединяли или откладывали JS через плагин оптимизации, бесконечный скролл мог перестать инициализироваться. Тогда либо исключите его файл из минификации, либо не используйте бесконечную подгрузку на страницах, где критична стабильность.
Безопасность и производительность
Любая логика, которая меняет навигацию по архивам, должна быть предсказуемой. Не вставляйте правки прямо в родительскую тему: при обновлении они исчезнут. Для точечных изменений используйте дочернюю тему или mu-plugin.
Если архивы большие, бесконечный скролл может создавать лишние запросы к базе и нагружать фронтенд, особенно если вместе с ним грузятся тяжёлые карточки, изображения и дополнительные блоки. В таких случаях лучше оставить пагинацию на разделах с большим количеством записей и использовать скролл только там, где он действительно улучшает UX.
Если вам нужно не просто отключить скролл, а ещё и убрать дубли страниц, canonical-ошибки и лишние архивы, сначала разнесите ответственность: тема отвечает за вывод, SEO-плагин — за индексацию, а оптимизация — за скрипты и стили. Так проще отлавливать конфликты и не ломать весь архив одним изменением.