AI Personalisation Without Cloaking Penalties or Speed Regressions
Personalisation and SEO pull against each other. One wants each visitor to see something different, the other needs a stable page a crawler can index and an engine can quote. Both goals are achievable together, but only if you decide deliberately which parts of the page are allowed to change.
Does personalised content hurt SEO?
Only when it changes the primary content based on who is asking, or when it slows the page down. Adjusting recommendations, calls to action and module order is fine. Serving crawlers different main content from users is cloaking, and that distinction is about intent as much as mechanics.
Where the cloaking line actually sits
The test is whether a crawler receives materially different primary content from a typical user. Safe by that standard: personalised product recommendations, geo-adjusted currency and stock, reordered modules, different calls to action, returning-visitor messaging.
Not safe: different headings, body copy or offers shown specifically because the request came from a crawler; keyword-stuffed variants served to bots; hidden text visible only to crawlers.
The practical rule is simple. Whatever a crawler sees should be what a first-time visitor with no history sees. Personalise on top of that baseline, never instead of it.
The performance problem is the bigger risk
Most personalisation damage is not penalties, it is speed. The common pattern renders a generic page, calls a personalisation service, then swaps content in. That produces layout shift, delays the largest paint, and blocks interaction precisely when the user is trying to act. You lose Core Web Vitals to gain a conversion lift, and often lose more than you gain.
Three ways to avoid it:
- Edge personalisation. Decide variants at the CDN edge so the user receives already-personalised HTML. Fast, and crawlers still get the default variant.
- Reserve the space. If you must swap client-side, set explicit dimensions on the container so the replacement causes no layout shift.
- Keep it below the fold. Personalise the recommendation strip, not the hero. The visible-on-load region should be static.
Caching is where this gets expensive
Personalisation fragments your cache. Every variant is a separate cached object, and a naive implementation that varies on a full user identifier gives you a cache hit rate near zero. Personalise on coarse segments instead: country, device, new versus returning, three or four behavioural buckets. Coarse segments keep caching viable and capture most of the available lift, because the difference between eight segments and eight thousand is much smaller than vendors imply.
How to introduce it safely
- Baseline your Core Web Vitals from field data before launch.
- Ship on one template, not the whole site.
- Verify with a crawler-agent fetch that the default variant is what gets served.
- Watch indexation and field vitals for a month alongside conversion.
- Keep the conversion lift and the performance cost in the same report, so the trade is visible rather than assumed.
A free audit shows how your pages render to a crawler, which is the fastest way to confirm the default variant is intact.
Frequently asked questions
Is personalised content considered cloaking?
Only when crawlers receive materially different primary content from users. Personalised recommendations, geo-adjusted pricing, reordered modules and different calls to action are fine. Different headings or body copy served specifically to bots is not.
Does personalisation slow down my site?
It commonly does, because the usual pattern renders a generic page, calls a personalisation service, then swaps content in. That causes layout shift and delays interaction. Deciding variants at the edge avoids most of it.
How does personalisation affect caching?
It fragments the cache, since every variant is a separate cached object. Varying on a full user identifier drives hit rates near zero, so personalise on coarse segments such as country, device and new versus returning.
What should crawlers see on a personalised page?
The same content as a first-time visitor with no history. Treat that as the baseline you personalise on top of, never a separate variant produced because the request came from a bot.
Where on a page is it safe to personalise?
Below the fold, in recommendation strips, related content and calls to action. Keeping the hero and the visible-on-load region static protects largest contentful paint and avoids layout shift.
How do I launch personalisation without risking rankings?
Baseline Core Web Vitals from field data, ship on one template, verify with a crawler-agent fetch that the default variant is served, then watch indexation and field vitals alongside conversion for a month.
Want this done for your site?
Run a free audit and see exactly what to fix for Google and AI search.