Fix by stack

Where the parity goes, and how to get it back.

Six patterns account for most of the readable content Lantad measures as missing. Each one has a specific cause in a specific stack, and a change your developer can make this week.

The six

Cause and fix, by stack

Ordered by how often the scanner raises them. The stack column is where we see the pattern most, not the only place it happens.

Stack What causes the loss The change
Next.js Content fetched inside a client component Move the fetch to a server component, or pre-render the route.
React, Vue A single-page-app shell with no server rendering Add server rendering, or generate static HTML at build time.
Shopify Review, FAQ and recommendation apps injected after load Render the app content into the Liquid template, or mirror it in the source.
WordPress Page builders that lazy-render everything below the fold Disable lazy render for text blocks. Images can stay lazy, copy cannot.
Any stack Tabs and accordions that mount their panel text on click Ship the panel text in the HTML and hide it with CSS, or use a native details element.
Any stack Consent walls and bot challenges served ahead of the content Let named AI crawler user agents through at the edge, or serve them the same HTML.

A linked stack name opens the full guide for that stack. Framer and Lovable are covered by guides of their own in the section below.

The principle

One rule underneath all six

Every fix on this page is the same idea applied to a different tool: the words have to be in the response, not assembled after it.

Ship text in the response

If a human would need it to understand the page, it belongs in the HTML your server returns. Everything else can hydrate afterwards.

Hide with CSS, not with JavaScript

A collapsed accordion whose text is in the DOM and hidden with CSS is fully readable. One that inserts its text on click is invisible.

Lazy-load images, never copy

Deferring images is good practice and costs you nothing here. Deferring paragraphs is the single most common cause of a low score.

Check the edge, not just the app

A perfect render path still scores zero if your CDN serves a challenge page to GPTBot. Access and parity are separate sub-scores for this reason.

The loop

How to work the fix list

The report ranks by impact rather than by severity label, so the order it gives you is the order worth working.

  1. Start with the biggest parity loss

    One block carrying 40% of the page's words outranks four small findings. The ranking already accounts for this.

  2. Fix the template, not the page

    If the same defect appears across a multi-page scan, it is one change in one template rather than eight separate tickets.

  3. Re-scan before you close the ticket

    The scan is free and takes under a minute. A fix that did not move the number is a fix that did not work.

  4. Watch the next deploy

    Parity regressions are silent: nothing looks wrong in a browser. Monitoring exists because this is the failure mode that comes back.

Almost every parity problem is one of six things. Content fetched inside a client component, a single-page-app shell with no server rendering, storefront apps injected after load, page builders that lazy-render text, tabs and accordions that mount panel text on click, and consent walls served ahead of the content.

None of these are exotic. They are the default behaviour of popular tools, which is exactly why so many sites have the problem without knowing it.

Common questions

Which of these is most common?

Client-component fetching on Next.js and app-injected content on Shopify, by a distance. Both are the framework's default path rather than a mistake, which is why they show up on sites built by people who know what they are doing.

Is server rendering the only answer?

No. Static generation at build time works just as well, and for most marketing pages it is simpler. The requirement is that the words are in the response, not which mechanism put them there.

Do I have to fix everything?

No. The list is ranked by impact because the top item is usually most of the problem. Clearing the first one or two findings typically moves a score more than clearing the remaining six.

What about content that genuinely needs JavaScript?

Interactive tools, dashboards and configurators are not the problem. The problem is prose behind JavaScript. If a paragraph explains what you sell, it belongs in the HTML; if it is a live calculator, nobody expects a crawler to run it.

Will fixing this hurt performance?

Generally the opposite. Server-rendered or pre-rendered text arrives faster than text fetched in a second round trip after hydration, so the same change usually improves both the parity score and time to first contentful paint.

Find out which of the six is yours.

The scan names the pattern, shows the words that went missing, and links the fix for your stack. Free, no signup, under a minute.