Edge-кеширование и персонализация: как не сломать SEO и не утечь данными

Финальная статья серии — и самая прикладная для того, у кого WordPress + PHP + VPS с Cloudflare впереди. Весь спор серии шёл про «где исполнять код»; здесь вопрос другой и он опаснее: как отдавать персональный контент с края, где физически один кэш на всех. Любая персонализация на edge живёт в том же shared-кэше, что и анонимный контент. Утечка через кэш — это не теоретический риск из учебника по безопасности, а основной способ, которым edge-персонализация ломается на практике. И ровно так же кэш ломает SEO: он держит устаревший редирект, отдаёт noindex не тому и превращает заботу о скорости в cloaking, если сегментировать по User-Agent.

Все цитаты о дефолтах и поведении кэша — из developers.cloudflare.com/* на снимок 2026-11-06 (даты «Last updated» по каждой странице вынесены в дисклеймер); я сверил их напрямую, а не по памяти. Одно важное предупреждение по фреймингу заранее: в актуальной доке НЕТ формулировки «Cloudflare не кэширует запросы, содержащие Cookie» — это широко повторяемый миф. Реальные защитники описаны в Части I дословно. Точные тарифные границы (на каком плане доступна та или иная опция ключа/правила) двигаются — сверяйте по документации в день внедрения.

Часть I. Как устроен edge-кэш и почему он обычно защищает вас сам

1. Shared-кэш: в этом и весь риск

Edge-кэш физически — одно хранилище на много пользователей: объект, положенный в PoP по одному URL, отдаётся следующему, кто придёт на тот же URL с тем же cache-ключом. Это и есть причина, по которой «кэш + персонализация» — отдельная дисциплина, а не «включил CDN и забыл». На VPS у вас тоже может быть shared-кэш (страница в Redis-фронте), но вы про него помните; на edge он по умолчанию, глобален и на сотни PoP, и забыть про него стоит утечки.

2. Три дефолтных предохранителя — дословно

Cloudflare по умолчанию не трогает персональный контент. Не потому, что «смотрит куку запроса», а по трём независимым правилам. Каждое — цитата из официальной доки (страница «Default Cache Behavior», Last updated 2026-09-14):

«Cloudflare only caches based on file extension and not by MIME type. The Cloudflare CDN does not cache HTML or JSON by default.»

Первая защита: персональные страницы — это HTML, а HTML по умолчанию вообще не кэшируется. Кэшируется только набор статических расширений (картинки, CSS/JS, шрифты, видео — JPG, CSS, JS, WOFF2, MP4 и т. п.). Ваш логин, аккаунт, корзина, профиль — HTML, они «по умолчанию вне кэша».

Вторая защита, на случай если HTML всё-таки в кэшируемом пути:

«Cloudflare does not cache the resource when:

The Cache-Control header is set to private, no-store, no-cache, or max-age=0.

The Set-Cookie header exists.

The HTTP request method is anything other than a GET.»

Обратите внимание на точный адресат: препятствует кэшированию Set-Cookie в ОТВЕТЕ origin, а не заголовок Cookie в запросе. Типичный персональный ответ (залогиненная страница) почти всегда несёт Set-Cookie (сессия, токен), и при включённом по умолчанию Origin Cache Control («Free, Pro and Business customers have this feature enabled by default») такой ответ уйдёт со статусом BYPASS и не попадёт в кэш.

3. Миф, который надо снять

В около-SEO-сообществах живёт фраза: «Cloudflare не кэширует запрос с Cookie». В актуальной доке такой формулировки нет. Что реально следует из цитат выше и из «Cache Keys» (Last updated 2026-10-30) — дефолтный ключ строится из URL и «a handful of specific headers», и Cookie запроса в него не входит. Значит «защита по куке запроса» — это не свойство ключа вообще. Настоящая защита (два пункта §2) устроена иначе, и важно понимать разницу по двум причинам:

она объясняет, почему обычно безопасно (HTML + Set-Cookie), а не «магически из-за куки»;
и она объясняет, почему можно сломать: раз кука запроса в ключ не входит, то при принудительном кэшировании ответ анонима и ответ залогиненного дадут один и тот же ключ — и это механизм слияния, из которого растёт утечка (Часть II). Миф «кука защищает» опасен именно тем, что усыпляет: человек включает Cache Everything, думает «ну кука же есть», и получает отдачу чужого HTML.

4. Cache lock и TTL по статусам — кэш не «накапливает» origin

Две детали, важные для понимания «как ведёт себя кэш под нагрузкой», тоже дословно из доки: одновременные промахи на один asset из одной локации сводятся к одному походу в origin — «Cloudflare only sends one request at a time to the origin for a given asset … preventing the origin from receiving excessive traffic» (cache lock). И если директив Cache-Control/Expires нет, кэш использует TTL по статус-коду: «200, 206, 301 → 120m, 302, 303 → 20m, 404, 410 → 3m. All other status codes are not cached by default». Запомните 301 → 120m — к Части IV про SEO этот редирект-кэш вернётся.

Часть II. Как именно утекает: три документированных вектора

Тезис серии — «утечка через shared-cache это основной способ поломки». Покажем его не абстракцией, а тремя конкретными путями, каждый с цитатой вендора.

1. Вектор №1 — `Cache Everything` + `Edge Cache TTL` снимает `Set-Cookie`

Это главный и самый частый сценарий. Страница «Head Requests and Set-Cookie Headers» (Last updated 2026-05-06) перечисляет три поведения кэшируемого ответа с Set-Cookie, и критично третье:

«Set-Cookie is returned from origin, the cache level is set to Cache Everything in Page Rules, or Eligible for cache in Cache Rules, and edge cache TTL is explicitly set using either the «Ignore cache-control header and use this TTL» or «Status code TTL» setting. In this case, Cloudflare removes the Set-Cookie and the asset is cached.»

Разложите на что это похоже для вас: вы, желая «ускорить WordPress», ставите Page Rule Cache Everything + Edge Cache TTL. Теперь персональный HTML кэшируется, а его Set-Cookie вырезается перед кладкой в кэш. Последствия двойные и оба плохие:

Утечка тела: закешированный «ваш» аккаунт/корзина отдаётся следующему на тот же URL (помните §I.3: кука запроса не в ключе → один ключ на всех).
Слом CSRF/сессий: срезанный Set-Cookie — это и токены CSRF, и сессионные идентификаторы. Формы на кэшированной странице перестают работать корректно: токен формы не привязан к сессии получателя.

Дока troubleshooting («Dynamic content and login issues», Last updated 2026-04-17) описывает ровно эту конфигурацию и даёт прямую рекомендацию дословно:

«Dynamic pages such as login forms, checkout flows, and authenticated application routes can break when they are cached too aggressively.» «In this configuration, Cloudflare can cache the response and remove the Set-Cookie header before the response is stored at the edge.» «Do not cache login pages or other authenticated HTML.»

2. Вектор №2 — web cache deception (персональный контент под видом статики)

Ещё один путь «утечки в кэш», который не про Cache Everything, а про обман самого дефолта «не кэширует HTML». Страница «Cache Deception Armor» (Last updated 2026-05-06) определяет атаку дословно:

«A Web Cache Deception attack tricks a user into visiting a URL that appears to point to a static asset but actually returns dynamic, personalized content from the origin. … Because the path ends in .jpg, Cloudflare caches the response by default. The attacker then visits the same URL and receives the cached copy of the user’s personalized content.»

Механика для PHP-программиста: /account/billing.css или /profile/x.jpg — путь «выглядит» как статика (расширение из кэшируемого списка), но ваш роутер отдаёт туда динамический персональный HTML. Дефолт про расширение срабатывает против вас: Cloudflare кладёт это в кэш (это же .jpg), отдача идёт без вашего Set-Cookie-сигнала, злоумышленник читает чужой профиль. Документированная защита — «Cache Deception Armor»: «the rule will verify a URL’s extension matches the returned Content-Type. … When a mismatch … is found, Cloudflare does not cache the response.» И важная оговорка из той же страницы, которую нельзя терять:

«Keep in mind that Cache Deception Armor depends upon Origin Cache Control. A Cache-Control header from the origin, or an Edge Cache TTL Cache Rule may override the protection.»

То есть та же связка «Edge TTL» из вектора №1 выключает и эту защиту. Один предохранитель, снятый ради скорости, ломает сразу два слоя.

3. Вектор №3 — сегментация по куке: от фрагментации к слиянию

Третий путь — не «баг», а цена попытку кэшировать персонализацию как ни в чём не бывало. Если включить куку/пер-юзер-заголовок в cache key «в лоб», ответ перестаёт быть общим: один уникальный key на каждого пользователя → cache sharding (дока прямо предупреждает: custom keys «may reduce your cache hit rate and result in cache sharding»). Кэш вырождается в «каждый со своей копией», вы платите storage-операциями и латентностью «including large values (such as cookies) in the cache key may increase per-request latency», а защиты это не даёт — если ключ собран неправильно (например, presence куки вместо значения, либо значение не проверено на принадлежность), два разных пользователя могут дать коллизию на одном ключе. Этот вектор — мост в Часть III: сегментировать можно и нужно, но только правильно устроенным ключом/правилом, а не «включил куку в key и забыл».

Часть III. Как делать персонализацию правильно: Vary, custom key, bypass, APO

1. `Vary` — поддерживается, но для куки/UA это bypass, а не сегмент

Честный ответ на вечный вопрос «можно ли положиться на Vary: Cookie». Состояние 2026 года: Vary на Cloudflare поддерживается (страница «Vary», Last updated 2026-08-14) — раньше дефолт был «игнорируем», теперь «When Cloudflare caches a response with a Vary header, the listed request headers become part of the cache key … following … RFC 9111». Но это не значит «пишите Vary: Cookie и всё само разложится». Три факта из доки, которые это ограничение и задают:

Дефолт без настройки правила всё же игнорирует vary — из «Cache-Control» (2026-06-30): «vary — By default, Cloudflare does not consider vary values in caching decisions» (учитывается, когда настроен через Cache Rules / Vary for images / accept-encoding).
Vary: * всегда мимо кэша: «A response containing Vary: * always bypasses cache, regardless of your Vary configuration.»
И главное — для пер-юзер-значений вендор не советует сегментировать, а советует bypass: три действия Vary-настройки — normalize / passthrough / bypass, а у bypass прямое назначение из доки: «Headers with too many possible values, per-user values, or values you do not want cached». Из «Cache Rules settings» (2026-10-15) — рекомендация дословно: «Use bypass for high-cardinality headers such as user-agent, cookies, or request headers with per-user values.»

Вывод для читателя: полагаться на Vary: Cookie как на механизм безопасной персонализации нельзя и не нужно. Правильное применение Vary на Cloudflare — это «разложить по языку/типу контента» (Accept-Language, Accept), где нормализация реально улучшает hit-rate; для куки/UA корректный ход — bypass, то есть вообще не кэшировать персональный ответ. Сегментация по куке делается ниже — ключом или правилом, а не Vary.

2. Custom Cache Key — когда сегмент по куке всё-таки нужен (Enterprise)

Если архитектура действительно требует несколько кешированных версий по признаку пользователя (например, «платный/бесплатный» тариф как два сегмента), это делается включением куки/заголовка в cache key, но с двумя ценами из доки («Cache Keys», 2026-10-30):

включение куки в custom key — опция высокого тарифа (в дефолтном ключа её нет; добавляется только явно настроенным custom key, доступность по плану — сверяйте);
«Custom cache keys … may reduce your cache hit rate and result in cache sharding» и «Including large values (such as cookies) in the cache key may increase per-request latency».

Практически: для большинства связок «сегмент по куке» — ложная цель. Обычно правильнее развести по путям: статика (/wp-content/…) — кэшируется, персональные роуты (/login, /account, /cart, /checkout) — bypass. Это ровно документированная рекомендация вендора (см. §II.1: «Restrict Eligible for cache … to static paths only. Add a more specific Cache Rule that bypasses … for routes such as /login, /account, /cart, /checkout»).

3. `Bypass Cache on Cookie` — дешёвый и безопасный дефолт вместо сегментации

Есть и промежуточный, самый практичный инструмент: Page Rule-настройка Bypass Cache on Cookie (доступность по плану — Business/Enterprise; сверяйте) — «Bypass cache and fetch resources from the origin server if a regular expression matches against a cookie name present in the request.» То есть: не сегментировать персональное, а не кэшировать запрос, если есть кука-признак (сессия, «logged_in»). Для WordPress это часто точнее и дешевле, чем Cache Everything с сегментом: один regexp (wordpress_logged_in_*, woocommerce_*) → весь персональный трафик уходит на origin, а статика и анонимный HTML остаются в быстром кэше.

4. APO для WordPress — безопасный дефолт целиком (и почему он ваш случай)

Для связки WordPress + Cloudflare существует готовый правильный ответ — Automatic Platform Optimization (APO), реализованный, заметим, на тех самых Workers из №4 («Automatic Platform Optimization is the result of using the power of Cloudflare Workers to intelligently cache dynamic content» — из описания вендора). Суть из страницы «About» (Last updated 2026-09-16):

«Cloudflare typically only caches static content, but with APO, we can also cache dynamic content — like HTML — to serve the entire site from the cache.» «Additionally, for logged-in or administrator users, we bypass the cache to ensure that private content is not cached and served to other visitors.»

И это не обещание «доверься», а формализованный список критериев, при невыполнении любого запрос идёт на origin (cf-cache-status: DYNAMIC, причина в cf-apo-via). Дословно релевантные пункты: кэшируется как HTML только когда «No bypass cookies are present (for example, logged-in, session, or WooCommerce cookies)»; когда заголовок плагина «permits caching (… cache,platform=wordpress, and not no-cache)»; и «The URL path is not an excluded path (such as checkout, wp-cron.php, or feeds)». Плюс отдельная страница (Last updated 2026-04-16): «if there are query parameters in the URL, APO bypasses the cache» (кроме allowlist маркетинговых параметров).

Практический вывод для аудитории сайта: если у вас WordPress на VPS с Cloudflare и вы хотите edge-скорость без ручной сборки правил — APO и есть та безопасная граница, которую вы иначе городите вручную (bypass по кукам, исключение checkout/feeds/параметров). Это прямо отвечает на «нужен ли edge WordPress» из №4/№5: не вычисления на краю — а кэш анонимного HTML на краю, с документированным обходом залогиненного.

Часть IV. Как кэш ломает SEO — и где кончается cloaking

1. Кэш сам по себе — НЕ cloaking

Распространённый страх «edge-кэш = показ разного контента = наружу» надо снять корректно. Cloaking — это когда роботу и человеку отдают разный контент (разное тело HTML по признаку «ты бот»). Сам по себе edge-кэш к этому не причастен, и вот почему — механизм: поисковые и LLM-краулеры не хранят и не шлют куки (это стандартное поведение всех ботов: Googlebot, Bing, YandexBot, LLM-краулеры). Значит краулер приходит без куки → попадает в анонимный cache key / в DYNAMIC-ответ origin, ровно как анонимный пользователь. Анонимный пользователь и краулер видят одно и то же тело — это не cloaking, это корректно закэшированная публичная страница. Персональный сегмент (залогиненный) просто невиден краулеру, потому что краулер в него не попадает по определению.

Cloaking начинается там, где вы сами в кэше или в правиле разводите ответ по User-Agent/«is-bot»: сегмент «Vary: User-Agent» или правило «ботам — один HTML, людям — другой». Поэтому и в сегментации по кэшу вендор рекомендует обходиться с UA как с high-cardinality → bypass: «Use bypass for high-cardinality headers such as user-agent». Не различайте робота и человека в ответе — и кэш не станет cloaking.

2. Кэш держит устаревший redirect (и это canonical-сигнал)

Из дефолтных TTL Части I: «200, 206, 301 → 120m». 301 Moved Permanently — это и несущий canonical-редирект, и тот, что вы правите при переезде URL. Кэшированный на 120 минут в сотнях PoP, он переживёт вашу правку: origin уже отдаёт новый Location, а край ещё 2 часа крутит старый. Для SEO это значит: меняли редирект/canonical — не ждите TTL, делайте purge по изменённым URL. (Заметим и про 307/308 — их в списке дефолтного TTL нет, они кэшируются только если явно разрешили директивы origin. Точное поведение по плану — сверяйте.)

3. `noindex` и метаданные не должны «засолить» всех

Если персональный ответ несёт X-Robots-Tag: noindex или иную мету, предназначенную одному контексту, а ответ попал в общий кэш — закешированный заголовок унаследуют все до протухания кэша. Прямой страницы Cloudflare именно про noindex × кэш в доке нет (честно: не подтверждено; механизм — общий для любого shared-HTTP-кэша), но следствие из Части I–II тривиально: раз HTML по умолчанию не кэшируется и ответ с Set-Cookie не кэшируется, то корректно настроенный (не Cache Everything) сайт не «зольёт» conditional-noindex на всех — вы сами сломаете это, включив принудительное кэширование персональных путей. То есть лечение то же: не кэшировать Cache Everything роуты, где меты контекстные.

4. «На всякий случай всё в `no-store`» — тоже ошибка, и платная

Симметричная ловушка: от греха подальше обернуть весь сайт в no-store/no-cache. Это защитит от утечки ценой убитого кэша. Прямое предупреждение из доки: «Setting no-store Cache-Control or a low TTL … increases requests to origin web servers and decreases performance» (страница конфигурации статусов кэша, 2026-09-04). Иными словами: персональное — не кэшируем (bypass/private/no-store), публичную статику и анонимный HTML — кэшируем с умом. Граница не «кэш vs безопасность», а «какой путь куда».

Часть V. Практический чек-лист безопасного кэша (WordPress + Cloudflare)

Собираю Части I–IV в порядок действий для связки «WordPress + PHP-FPM на VPS + Cloudflare впереди». Это не догма, а применение цитат; конкретные имена кук/плагинов подставьте свои.

Начните с дефолта и не ломайте его. Не ставьте Cache Everything на весь сайт глобально. Дефолт уже защищает: HTML/JSON не кэшируются, ответ с Set-Cookie не кэшируется (Origin Cache Control на Free/Pro/Business включён). Ваш первый шаг — ничего не включать, а смотреть CF-Cache-Status на реальных URL (curl -sI https://example.test | grep -i cf-cache-status): HIT на статике — ок; HIT на /account — это и есть баг.
Кэшируйте статику по путям, не «всё». Eligible for cache/Cache Everything — только на статические пути (/wp-content/…, ассеты). Документированная рекомендация вендора дословно: «Restrict Eligible for cache or Cache Everything to static paths only.»
Bypass для персональных роутов. Явные bypass/disabled-кэш правила на /login, /account, /cart, /checkout, админку wp-admin, API-пути. Проверка, что починилось, — тоже из доки: ответ должен вернуться с CF-Cache-Status: DYNAMIC/MISS/BYPASS и сохранённым Set-Cookie.
Или один regexp по куке. Bypass Cache on Cookie по wordpress_logged_in_* / woocommerce_* / сессионным кукам — весь персональный трафик на origin, статика и анонимный HTML в кэше. (Это альтернатива ручной россыпи путей, доступность по плану — сверяйте.)
Для WordPress по умолчанию поставьте APO вместо самоделок. APO даёт «cache HTML, но bypass для logged-in/admin», обходит checkout/feeds/параметры и синхронизирует инвалидацию при обновлении поста. Это ровно безопасная граница, собранная вендором; городить её Page Rules’ами вручную — путь к той же утечке из Части II.
Включите Cache Deception Armor и держите origin-контент-тайп честным. Защита «расширение ↔ Content-Type» против вектора №2. Помните оговорку: Edge TTL-правило её переопределяет — то есть пункты 2/3 («не ставить Edge TTL на персональное») — это и есть условие работы Armor.
Для персонального, которое надо отдавать быстро, — private в origin, а не кэш на краю. Cache-Control: private, max-age=… = «кэшируй в браузере, но не в shared-кэше» — прямое определение из доки («must not be stored by a shared cache like Cloudflare»). Секретное и одноразовое (CSRF, платёжное) — no-store.
После правки редиректов/canonical — purge. 301 живёт в кэше 120 мин (§IV.2); меняли карту редиректов — сделайте purge по изменённым URL, не ждите TTL.
Не сегментируйте по User-Agent в кэше. Ни Vary: User-Agent, ни правил «боту — другое». Иначе включается §IV.1 cloaking; а вендор и так советует UA → bypass.

Частые комбинации «хочу → как надо»

Вы хотите	Неправильно	Правильно (и почему)
«Ускорить WordPress»	Page Rule `Cache Everything` + `Edge TTL` на `*`	APO (bypass залогиненного) или `Cache Everything` только на статику + bypass персонального
«Залогиненное не утекло»	Положиться на миф «кука защищает» / `Vary: Cookie`	не трогать дефолт (`Set-Cookie`→BYPASS) или `Bypass Cache on Cookie`; персональное — `private`/`no-store` на origin
«Бот видел то же, что юзер»	`Vary: User-Agent`, правило «is-bot → другой HTML»	ничего: бот без куки → анонимный ключ = тот же ответ; UA → `bypass`
«Изменил редирект — сразу работает»	ждать TTL	purge по URL (`301` кэшируется 120m)
«Безопаснее будет всё в no-store»	`no-store` на всём сайте	no-store только персональное/секретное; публичное кэшировать (иначе «decreases performance»)

Часть VI. Итог серии: оси выбора и ось кэша

Серия началась («Cloudflare купил Deno: что это реально значит») с тезиса, что покупка — это разворот не к Cloudflare, а к переносимой модели. Дальше были механика переноса (№2), self-host распределённого состояния (№3), примитивы «другой экономики данных» (№4) и матрица выбора по осям (№5). Эта, шестая, добавляет к матрице Части V из №5 ещё одну ось, без которой выбор «а, включу-ка я edge-кэш» остаётся наивным:

Ось «общий или сегментированный ответ». В №5 вы решали, где исполнять и где состояние. Здесь вы решаете, что можно положить в один кэш на всех, а что нет. Ответ простой и повторяет формулу серии: публичное и не зависящее от пользователя — кэшируется на краю; персональное и секретное — не кэшируется (bypass), кэшируется в приватном браузере (private) или вообще no-store. Граница там же, где всегда в этой серии: «локально отвечает без состояния пользователя — на краю; нужен источник истины или контекст пользователя — у origin».

Итоговый практический вердикт для аудитории сайта: вам не нужно переносить WordPress на Workers, чтобы получить «edge». Ваш путь в edge — кэш: CDN для статики, APO (или аккуратные правила) для анонимного HTML, и дисциплина не кэшировать персональное. Утечка и поломка SEO — это не свойство edge-кэша, а свойство Cache Everything с Edge TTL, мифа «кука защищает» и сегментации по User-Agent. Всё остальное дефолт делает за вас — надо просто не мешать ему.

Три статьи-соседки для продолжения: «просто включить CDN» механически разбирает CDN и edge-вычисления; чем отличаются заголовки-«кэшируй меня» на уровне HTTP (RFC 9111: public/private/max-age) — Кеширование; а почему краулеры (поисковые и LLM) вообще не шлют куки и что из этого следует для видимости — llms.txt и LLM-краулеры: что реально влияет на цитируемость.

Инструменты под задачу

Разобрать ваши правила кэша и найти дыру утечки — AI-ассистент для кода на codestack.space: вставьте набор Page/Cache Rules и curl -sI ваших персональных URL и попросите пройтись по чек-листу Части V — где Set-Cookie срезается Edge TTL, где нет bypass на /account, и где 301 застрянет в кэше.

Чек-лист граблей

Вестись на миф «запрос с Cookie не кэшируется». В доке такой защиты нет. Реальные три (HTML/JSON по умолчанию не кэшируются; Set-Cookie в ОТВЕТЕ; кука запроса не в дефолтном ключе). Думая «кука спасёт», включают Cache Everything и получают слияние анонимного и персонального в один ключ.
Ставить Cache Everything + Edge Cache TTL на весь сайт. Это ровно документированный путь «Cloudflare removes the Set-Cookie and the asset is cached»: утечка тела + сломанный CSRF/сессии. Только на статику.
Считать Vary: Cookie безопасной сегментацией. Дефолт игнорирует vary; для per-user/кук/UA вендор советует bypass, не сегмент. Настоящий ключ по куке — custom cache key (высокий тариф) с ценой в sharding и латентность.
Разводить бота и человека в кэше (Vary: User-Agent, «is-bot → другой HTML»). Это и есть cloaking. Бот без куки уже получает анонимный ключ = то же тело, что юзер; не надо «помогать» ему другим HTML.
Ждать, что purge не нужен после правки редиректа. 301 кэшируется 120 мин по умолчанию; поменяли canonical/редирект — делайте purge, не ждите TTL.
Игнорировать web cache deception. /account/billing.css, отдающий динамический HTML, кэшируется «по расширению» и утекает. Включайте Cache Deception Armor — и не переопределяйте его своим Edge TTL (он «may override the protection»).
Класть conditional noindex/X-Robots-Tag в закешированный персональный путь. Закешированная мета унаследована всеми до протухания; персональное не кэшируется на краю — тогда не и течёт, и мета не «засолит» индекс.
Замазывать весь сайт в no-store «на всякий случай». Это «increases requests to origin … and decreases performance». no-store — только секретному/одноразовому; публичное кэшировать.
Городить APO-границу вручную для WordPress. Связка «bypass залогиненного + исключение checkout/feeds/параметров + инвалидация» — это APO; самоделки Page Rules воспроизводят ровно те дыры из Части II.
Считать цифры/планы из статьи финальными. Доступность (custom key по куке, Bypass Cache on Cookie по плану) и даты «Last updated» страниц двигаются — сверяйте по документации в день внедрения.

👤 Зарегистрируйтесь, чтобы добавить материал в закладки.