Ограничение контента в WordPress: типичные ошибки

В WordPress 6.x платный материал часто закрывают одним переключателем в плагине подписок, но это само по себе не защищает контент. Полный текст может остаться в HTML, попасть в кеш, RSS или REST API, а отменивший подписку пользователь — сохранить доступ до конца оплаченного периода. Ниже — практический разбор ошибок, которые возникают при ограничении контента, и проверок, позволяющих найти утечки до публикации.

Сначала определите, что именно вы закрываете

«Закрыть статью» может означать разные вещи: скрыть весь материал, оставить первые абзацы, разрешить доступ только активным подписчикам или открыть публикацию после определённой даты. Эти сценарии требуют разных настроек. Универсального переключателя для всех WordPress-сайтов нет.

Материал рассчитан на WordPress 6.x. Плагины membership и subscription меняют названия пунктов меню, правила доступа и поведение кеша от версии к версии, поэтому конкретные настройки нужно сверять с документацией установленного расширения.

Три способа ограничить публикацию

Проверка в шаблоне сама по себе не решает задачу, если полный текст уже доступен через REST API или сохранён в публичном кеше. Поэтому важно защищать не только внешний вид страницы, но и каждый канал выдачи данных.

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

Ошибка 1. Прятать текст только стилями

Схема с display: none, затемнением блока или кнопкой «Показать после подписки» выглядит быстро, но не защищает данные. Браузер сначала получает HTML, а CSS лишь меняет его отображение. Читатель может увидеть текст в исходном коде страницы, инструментах разработчика или ответе сервера.

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

Ошибка 2. Проверять роль вместо права на контент

В WordPress роль — это набор разрешений, а не подтверждение оплаченной подписки. Пользователь может оставаться участником роли после отмены платежа, получить роль по ошибке или иметь её по другой причине. Обратная ситуация тоже возможна: действующая подписка есть, но синхронизация роли ещё не завершилась.

Правило доступа должно учитывать состояние подписки, дату окончания оплаченного периода и конкретный уровень доступа. Если плагин предоставляет собственную проверку членства, используйте её, а не ручное сравнение имени роли. Функция current_user_can() подходит для проверки разрешений WordPress, но не заменяет проверку статуса подписки.

Что проверить после покупки и отмены

• новый пользователь получает доступ только после подтверждённого платежа;
• пользователь с активной подпиской видит полный материал;
• после отмены доступ сохраняется или прекращается именно по правилам тарифа;
• после окончания оплаченного периода полный текст больше не выдаётся;
• администратор и редактор не получают случайно тот же ответ из публичного кеша, что и обычный посетитель.

Ошибка 3. Забыть о полном тексте в HTML и REST API

Ограничение может работать на странице записи, но не работать в других представлениях. Проверьте URL записи в режиме гостя, ответ REST API, RSS-ленту, поиск по сайту, AMP или отдельную мобильную версию, если они используются.

Для REST API особенно важен тип ответа: запись может отдавать полный контент в поле content, даже если визуальный шаблон показывает только отрывок. Не пытайтесь закрыть это JavaScript-кодом после загрузки страницы: клиент уже получил данные.

Изображения требуют отдельной проверки. Если платный материал содержит оригинальные файлы в стандартной папке загрузок, знание прямого URL может обойти ограничение. Водяной знак не является контролем доступа, а закрытие изображения в интерфейсе не запрещает загрузку файла.

Ошибка 4. Не учесть кеш

Это одна из самых дорогих ошибок. Первый посетитель без подписки может получить заглушку, а подписчик — тот же закешированный ответ. Бывает и наоборот: кеш сохраняет полную версию после авторизованного запроса и отдаёт её гостям.

Проверяйте не только кеш WordPress, но и все уровни перед ним: плагин оптимизации, серверный кеш, CDN и кеш браузера. Авторизованные и неавторизованные запросы должны обрабатываться по правилам, которые поддерживает конкретная связка.

Минимальный тест для кеша

1. Откройте закрытую запись в приватном окне браузера и убедитесь, что полный текст не виден.
2. Войдите тестовым пользователем с активной подпиской и проверьте доступ.
3. Выйдите из аккаунта, очистите только кеш страницы и снова откройте URL.
4. Повторите проверку с другого устройства или через мобильную сеть.
5. Проверьте заголовки ответа и настройки CDN, если сайт использует прокси-кеш.

Результат считается корректным, если гостю всегда приходит заглушка, а подписчику — полный материал, независимо от того, кто первым открыл URL.

Ошибка 5. Показать в тизере слишком много

Ограничение первых абзацев часто превращается в публикацию почти всего материала. Полный текст может попасть в ручной отрывок, SEO-описание, подпись изображения, блок «похожие записи» или структурированные данные.

Сделайте тизер самостоятельным: объясните проблему, укажите цену вопроса и оставьте причину оформить подписку, но не публикуйте ключевой алгоритм, таблицу или финальный вывод. Проверьте исходный HTML и просмотр страницы в режиме гостя — не только то, что видно на экране.

Ошибка 6. Сломать редактор блоков

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

Создайте тестовую публикацию с заголовками, изображением, списком, цитатой, таблицей и вложенными группами. Проверьте её в качестве гостя, подписчика и администратора. Если правило задаётся для всей записи, убедитесь, что оно не оставляет доступ к отдельному блоку через поиск или REST API.

Ошибка 7. Разрешить доступ поисковикам без понятной модели

Иногда владелец сайта хочет, чтобы поисковые системы видели полный текст, а пользователи без подписки — только часть. Это маркетинговый выбор, а не техническая защита: опубликованный для поискового робота контент потенциально доступен и другим клиентам, если проверка построена на ненадёжном признаке.

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

Где подход ломается

Даже корректное правило доступа не спасает от ошибок вокруг него. Самые сложные случаи обычно связаны не с выводом статьи, а с состоянием аккаунта и инфраструктурой.

• Платёж подтверждён, но доступ не выдан. Проверьте вебхуки, очередь фоновых задач и журнал событий платёжного сервиса.
• Доступ не отозван. Проверьте, что отмена и окончание периода передаются в WordPress, а не только меняют статус в платёжной системе.
• Гость видит полный текст после расшаривания ссылки. Проверьте кеш, превью в соцсетях и сохранённые версии страницы.
• Администратор видит всё, а тест не проходит. Используйте отдельные тестовые аккаунты: права администратора могут обходить ограничения.
• Закрыт текст, но открыт файл. Для защищённых материалов отдельно проектируйте выдачу изображений, документов и видео.

Практический чек-лист перед запуском

1. Запишите правила доступа: какой тариф, срок и статус дают право читать публикацию.
2. Проверьте гостя, активного подписчика, отменившего подписчика и пользователя с истёкшим периодом.
3. Откройте страницу, REST API, RSS, поиск и прямые URL вложений.
4. Очистите кеши и повторите тест в другом браузере и через другую сеть.
5. Проверьте продление, отмену, возврат платежа и задержку синхронизации.
6. Зафиксируйте версии WordPress, темы, плагина подписок и кеширующего слоя.

Что делать дальше

После запуска поставьте мониторинг не только оплат, но и ошибок выдачи доступа: долю неудачных проверок, задержку синхронизации подписки, ответы 4xx и 5xx, а также обращения пользователей, которые видят заглушку после оплаты. Раз в месяц повторяйте тест гостя и подписчика на нескольких закрытых публикациях.

Если сайт использует собственную интеграцию, начните с документации WordPress по хукам и проверке разрешений, а затем отдельно опишите контракт с платёжной системой: какие статусы приходят, когда меняется доступ и что происходит при задержке уведомления. Инвалидация кеша и защита файлов — отдельные темы; здесь важно не смешивать их с проверкой текста записи.

Сноска. Вебхук — это HTTP-уведомление от одного сервиса другому о событии, например об успешной оплате или отмене подписки. Если такое уведомление не дошло, WordPress может сохранить старое состояние доступа.