Do animations hurt your SEO? The mechanisms, and what to check
Animation does not carry an SEO penalty. Three specific things it can do to a page will cost you, and only one of them is about ranking. How to tell, before you license a template.
Published
The short answer
There is no ranking penalty for animation. Google does not have a rule that says a page which moves should rank below a page which does not, and nobody selling you either kind of template can show you one.
What exists instead are three specific, measurable things a badly built animated page does — and they are worth separating, because two of them are user-experience problems that only indirectly touch search, and the third is a genuine indexing problem that can cost you the page entirely.
It makes the page slow to respond when someone taps it. Measured as INP. A ranking signal, and a small one.
It makes the layout jump while loading. Measured as CLS. Also a ranking signal, also small.
It puts your words somewhere a crawler may never look. Not a ranking signal at all — an indexing one, and the only item on this list that can remove you from results rather than move you down them.
Almost every article on this subject spends its length on the first two and skips the third. The third is the one that actually decides whether an animated site works in search.
What Google actually measures
Three metrics, collectively Core Web Vitals. Each has a published threshold, and each is assessed at the 75th percentile of real page loads across mobile and desktop — so it is the experience of your slower quarter of visitors that counts, not your laptop on office wifi.
| Metric | What it measures | Good |
|---|---|---|
| LCP | How long until the biggest thing on screen has loaded | 2.5 seconds or less |
| INP | How long the page takes to respond to a tap, click or keypress | 200 milliseconds or less |
| CLS | How much the layout moves around while it settles | 0.1 or less |
INP is the one to know about, because it is both the newest and the one animation touches most directly. It replaced First Input Delay as a Core Web Vital in 2024. Where FID timed only the first interaction, INP watches every click, tap and keypress for the whole visit and reports near the worst of them. A page that feels fine on the first tap and stutters on the fifth used to score well and now does not.
Above 500 milliseconds INP is rated poor; 201 to 500 is "needs improvement". These are the published thresholds, not our estimates, and they are worth reading at the source — linked at the foot of this page.
Where animation actually costs you
Animation is not one technique, and the three ways it goes wrong have almost nothing to do with each other.
The first is main-thread contention, and it is the reason INP suffers. A browser has one thread for running your JavaScript and one for painting the page, and they are the same thread. Work scheduled on every scroll event — recalculating positions, reading layout properties, writing styles back — sits in the queue in front of the tap the visitor just made. The tap is not ignored; it is waiting its turn. On a mid-range phone, which is most phones, that queue is several times longer than on a development machine, which is why this problem is nearly invisible while you are building.
The second is layout shift, and it is usually not the animation at all. It is the images and embeds around it loading without their dimensions declared, so the page reflows as each one arrives and the paragraph someone was reading slides out from under them. An animated hero makes this worse only because animated heroes tend to be image-heavy.
The third is the one that matters, and it is a rendering problem rather than a performance one.
The real risk: words that are not in the HTML
Google processes a page in three phases — crawl, render, index — and rendering is a separate, queued step. Googlebot fetches the HTML, parses it for links, and queues the page for rendering in headless Chromium; the guidance notes pages may wait "seconds or longer before resources become available for rendering." Only the rendered output is indexed.
So a page whose text only exists after JavaScript runs is not invisible to Google. It is deferred, which is a different and more annoying problem: your content is indexed later than it could be, every change takes longer to register, and anything that goes wrong in that render — a script error, a blocked resource, a third-party timeout — silently costs you the content rather than the animation. Google recommends server-side or pre-rendering anyway, and is direct about the reason: it is faster for users and crawlers, and "not all bots can run JavaScript." The bots that cannot include most of what feeds AI answers and social previews.
This is the thing to check, and it takes about fifteen seconds. Open the template demo, view source, and search the raw HTML for a sentence you can see on the page. If it is there, the template renders its text as HTML and animates it afterwards. If the source is a near-empty div and a script tag, every word on that page depends on JavaScript running correctly, on a queue you do not control.
Run that check on this site if you like. Strip every script tag from the Formynex homepage and 755 words of copy remain in the raw HTML; do the same to a template detail page and 216 words remain. That is not a claim about how fast the site is — it is a claim about where the words live, which is the part that decides whether they can be indexed at all.
What 62 shipping templates actually do about it
We sell both halves of this argument, which makes the comparison worth something: 44 scroll-driven and 3D templates, and 18 conventional ones. Here is what is true across them, counted rather than asserted.
All 60 single-file templates respond to the operating system’s reduce-motion setting. Not most of them — all of them, verified by reading the sources. Decorative motion and smooth scrolling stand down for a visitor who has asked for that.
The 18 classic templates load no external JavaScript at all, and carry their photography inside the document rather than fetching it separately.
The scroll-driven half loads its 3D and timeline libraries from a CDN at a named build, so nothing is bundled and there is nothing to rebuild when you change the copy.
Card previews on this site are video, not the running template, and they are not fetched until the card approaches the viewport. The classic tier’s previews are not fetched until you hover one.
And here is what we will not tell you, because we have not measured it: how fast any of these templates is in the field. We publish no load times, no Lighthouse scores and no Core Web Vitals figures, because we have no field data and a number nobody stands behind is worth less to you than the thing we can offer instead — every demo on this site is public and unlocked. Open the one you are considering on the device your visitors actually use and scroll it. Thirty seconds of that beats any number we could put in a table.
What to check before you license any animated template
Six checks, in the order that eliminates candidates fastest. None needs a tool beyond a browser.
View source on the live demo and search for a visible sentence. Present in the HTML: good. Absent: everything below matters less, because indexing is already the bigger question.
Open the demo on a real mid-range phone, not a desktop browser resized. Scroll it hard, then immediately tap a navigation link. If the tap hangs, that is INP, and it will not improve on your content.
Watch the first three seconds without scrolling. If headings jump as images arrive, the template is not declaring its image dimensions, and that is CLS.
Turn on reduce motion in your operating system’s accessibility settings and reload. A template that ignores it is telling you what its author thinks of the setting.
Tab through it with the keyboard. Scroll-driven layouts are the easiest place to lose focus order, and a form you cannot reach by keyboard is a conversion problem before it is an accessibility one.
Ask what the animation is for. If the page still makes its argument with the motion removed, the motion is an enhancement. If it does not, you are buying a demo rather than a website.
The last one is not a technical test and it is the one that decides most purchases correctly.
When the conventional option is the right one
A scroll-driven scene is an argument for something with nothing photogenic to show. Infrastructure, an API, a consultancy, an AI product whose interface is a text box — the motion is doing the work that a photograph would do for a hotel.
If you have a listing grid, fourteen neighbourhoods and a search box, the motion is in the way. That buyer wants the search where they expect it and a page that loads before they change their mind. Choosing a conventional layout there is not settling for less; it is matching the page to the job.
Both halves of the Formynex catalogue are browsable on that division: the classic templates are the conventional ones, the 3D templates are the other extreme, and the full catalogue has a type filter if you would rather see them side by side.
What this guide cannot tell you
Whether any of this moves your rankings. Core Web Vitals are a ranking signal and a modest one; relevance, and whether the page answers what was searched for, outrank it comfortably. A fast page about the wrong thing does not win.
The thresholds quoted here were current when this was published and are linked below so you can check them rather than take our word. If you are reading this long after the date at the top, check them — Google changed the interactivity metric once already, in 2024, and the replacement measured something meaningfully different.
Sources
The published thresholds and guidance quoted above, at source. Everything said about the Formynex catalogue was counted from the templates themselves.
