Google saw 1 word on my Next.js homepage. A Suspense boundary was hiding everything else.

Arsany — Mon, 26 Oct 2026 18:20:09 +0000

Last night I ran an SEO audit on Ilytics, the analytics tool I've been building, and it came back with 0 words on every page.

I assumed the audit tool was broken. The site looked fine in my browser. So I fetched the homepage the way a crawler does, with curl and a Googlebot user agent, and counted the words in the HTML. There was exactly one: "Ilytics", from the page title. No headings, no text, no links to my other pages.

The fix ended up being about twenty lines. It's an easy mistake to make in the App Router, so I'm writing it up.

The provider that wrapped everything

My root layout wraps the whole app in an analytics provider, which is how most PostHog setups for Next.js look:

// app/layout.tsx
<PostHogProvider>
  {children}
</PostHogProvider>

Inside, the provider reads the URL so it can send a pageview whenever the path or query string changes. Because useSearchParams() needs a Suspense boundary, I had wrapped it in one:

"use client";

function PostHogInner({ children }) {
  const pathname = usePathname();
  const searchParams = useSearchParams();
  // ...init, identify, pageview tracking...
  return <PHProvider client={posthog}>{children}</PHProvider>;
}

export function PostHogProvider({ children }) {
  return (
    <Suspense fallback={null}>
      <PostHogInner>{children}</PostHogInner>
    </Suspense>
  );
}

Why that empties the page

When a statically rendered page calls useSearchParams(), Next.js can't know the query string at build time. So everything up to the nearest Suspense boundary gets rendered in the browser instead of on the server, and the server HTML contains the boundary's fallback.

My boundary wrapped {children}, which in a root layout is the entire site. The fallback was null. So every page was pre-rendered as nothing, and JavaScript filled it in after load.

Visitors never noticed because it happens in a fraction of a second. Crawlers that read the server HTML got an empty page.

The fix is to shrink the boundary

Only the part that reads the query string needs to wait for the browser. I moved pageview tracking into its own component, gave it its own Suspense boundary, and rendered children outside of it:

"use client";

function PageviewTracker() {
  const pathname = usePathname();
  const searchParams = useSearchParams();

  useEffect(() => {
    ensurePostHog();
    posthog.capture("$pageview", { $current_url: window.location.href });
  }, [pathname, searchParams]);

  return null;
}

export function PostHogProvider({ children }) {
  // session and identify logic stays here, without useSearchParams
  return (
    <PHProvider client={posthog}>
      {children}
      <Suspense fallback={null}>
        <PageviewTracker />
      </Suspense>
    </PHProvider>
  );
}

The boundary now wraps a component that renders null anyway, so nothing is lost, and the actual pages render on the server again.

One thing broke along the way. React runs a child component's effects before its parent's, so the tracker started calling capture() before the parent had called posthog.init(). I moved the init into a small ensurePostHog() function that both components call, with a flag so it only runs once.

Before and after

I fetched the same pages as Googlebot before and after deploying. Visible words in the HTML:

Home: 1 before, 375 after
Pricing: 0 before, 211 after
FAQ: 0 before, 159 after
Docs: 0 before, 138 after

Each page also went from zero to one H1, and from no internal links in the HTML to between 6 and 15.

How to check your own site

Run this against any page and compare the number with what you see in the browser:

curl -s -A "Googlebot" https://your-site.com/ \
  | sed -E 's/<script[^>]*>.*<\/script>//g; s/<[^>]+>/ /g' \
  | wc -w

If it's close to zero, look for useSearchParams() or other client-only hooks inside a Suspense boundary that sits high up in your layout.

Google does render JavaScript eventually, but it's slower and less reliable than reading HTML, and many other crawlers don't run JavaScript at all. I'd rather not depend on it.

What I'd check next time

If you add any tracking or auth provider to a Next.js layout, check where its Suspense boundary sits before you ship. The Next.js docs on useSearchParams explain the client-side rendering behavior in more detail.

It's a little embarrassing that the thing hiding my analytics product from search was an analytics provider. At least it made for a good debugging session.

Arsany

The EU Just Moved to Make Website Analytics Consent-Free. Here's the Catch.

Arsany — Sun, 25 Oct 2026 22:05:28 +0000

On October 21, 2026, EU ambassadors agreed the Council's position on the Digital Omnibus, a package that amends the GDPR and the ePrivacy rules. Buried in its 179 pages is a line every website owner should read: anonymous, first-party audience measurement could run without asking for consent.

In other words, simple analytics may no longer need a cookie banner. But there is a catch, and a long timeline.

What the Council agreed

The Council kept cookie rules where they are today, in the ePrivacy Directive. Consent stays the general rule. What changes is the list of exceptions: device access without consent would be allowed only when it is strictly necessary for one of six purposes.

One of those purposes is anonymous, aggregated audience measurement of your own service. It can be run by you or by a provider on your behalf, as long as the data is:

anonymous and aggregated
used only to measure your own service
not shared with third parties
not combined with third-party data
not reused for any other purpose

The mandate also requires a one-click way to refuse cookies, and bars sites from asking again for at least four months after a refusal. The Commission had proposed six.

What still needs consent

The exemption is narrow on purpose. Consent is still required for:

cross-site tracking
advertising profiles
analytics that merges your stats with outside data
anything that is not anonymous and aggregated

So the cookie banner is not dead. It is simply no longer meant for basic "how many people visited" analytics.

When it would actually apply

Nothing changes today. Here is the path ahead:

Step	Status
Council mandate agreed by Coreper	Done, Oct 21, 2026
European Parliament adopts its position	Not yet, as of Oct 24, 2026
Council and Parliament negotiate the final text	Starts after Parliament's position
Member states transpose the cookie changes	24 months after adoption

The EU wants its simplification packages done by the end of 2027, so legal analysts expect the cookie changes to take effect around 2028 at the earliest. Until then, current GDPR and ePrivacy rules apply in full.

Why it matters anyway

Even before it becomes law, the direction is clear. Europe is drawing a line between analytics that measures your own site and analytics that tracks people. The first is being made easier. The second keeps its friction.

For developers and founders, that means the less your analytics collects, the less it will cost you, both in legal work and in the visitors you lose to consent pop-ups.

I'm building Ilytics, a small analytics tool, around the same idea, so I'll be watching how Parliament's position turns out.

This article summarizes public reporting on a draft legislative position. It is not legal advice.

DEV Community: Arsany