This is the checklist I ended up with. Every item is something I actually found and fixed on a Next.js 15 App Router site. Each one has a way to check your own site in under a minute.

1. See your page the way a crawler does

Before changing anything, look at the HTML your server sends, not what your browser renders after JavaScript runs.

curl -s -A "Googlebot" https://yoursite.com/ | sed 's/<[^>]*>/ /g' | wc -w

This counts the words in the raw HTML. My homepage returned 1. After the fixes below it returned 375. If your number is tiny compared with what you see on screen, something is client-rendering your content.

2. useSearchParams can client-render your whole page

This was the big one. I had a pageview tracker that called useSearchParams(), wrapped in a <Suspense> that also wrapped {children} in the root layout.

The Next.js docs say that on a statically rendered route, useSearchParams makes the client component tree up to the closest Suspense boundary render on the client. My closest boundary contained the entire site.

The fix is to give the hook its own tiny boundary:

// app/providers.tsx
export function Providers({ children }: { children: React.ReactNode }) {
  return (
    <PostHogProvider client={posthog}>
      {children}
      <Suspense fallback={null}>
        <PageviewTracker />
      </Suspense>
    </PostHogProvider>
  );
}

Now only the tracker waits for the browser. Everything else renders on the server.

3. Set metadataBase

Without it, relative Open Graph image URLs and canonicals can't be turned into absolute URLs. Next.js warns about this in the terminal, and the warning is easy to miss.

// app/layout.tsx
export const metadata: Metadata = {
  metadataBase: new URL("https://yoursite.com"),
  title: { default: "Your product: what it does", template: "%s | Your product" },
};

4. One canonical per page

Each route should declare its own canonical, or Google picks one for you:

export const metadata: Metadata = {
  alternates: { canonical: "/pricing" },
};

For dynamic routes, return it from generateMetadata using the slug.

5. Don't repeat the brand twice in titles

With a title.template of "%s | Brand", a page whose own title is "Privacy | Brand" ends up as "Privacy | Brand | Brand". I had this on two legal pages. Give pages only the part before the separator.

6. Pages with "use client" can't export metadata

My pricing and FAQ pages were client components, so their export const metadata did nothing. They fell back to the homepage title.

The fix is a small layout.tsx next to the page that exports the metadata. The page itself stays a client component.

// app/(marketing)/pricing/layout.tsx
export const metadata: Metadata = {
  title: "Pricing",
  description: "One plan, 14-day free trial.",
  alternates: { canonical: "/pricing" },
};
export default function Layout({ children }: { children: React.ReactNode }) {
  return children;
}

7. Generate the sitemap from your real routes

A hand-written sitemap goes stale. app/sitemap.ts can build it from the same data your pages use:

import type { MetadataRoute } from "next";
import { DOCS } from "@/lib/docs";

export default function sitemap(): MetadataRoute.Sitemap {
  const base = "https://yoursite.com";
  const pages = ["", "/pricing", "/faq", "/docs"].map((p) => ({ url: base + p, lastModified: new Date() }));
  const docs = DOCS.map((d) => ({ url: `${base}/docs/${d.slug}`, lastModified: new Date() }));
  return [...pages, ...docs];
}

Mine went from 4 URLs to 15 once the docs pages were included.

8. Only put true things in structured data

My JSON-LD had an aggregateRating left over from a template, for reviews that didn't exist. Google's structured data guidelines say markup has to reflect content that's actually on the page, and made-up ratings can get the page a manual action.

I removed it and kept a simple @graph with Organization, WebSite and SoftwareApplication. I also deleted some leftover geo meta tags for a city I've never been to.

9. Tell search engines when things change

After deploying, I submitted the sitemap in Search Console and pinged IndexNow (used by Bing and Yandex). IndexNow needs a key file in public/, then one request with your changed URLs. Search Console shows changes over days, not minutes, so check back after a week.

The order I'd do it in

1. Run the curl word count.
2. Fix any Suspense or client-rendering bailout.
3. Add metadata, canonicals and titles.
4. Add the sitemap and clean up structured data.
5. Resubmit to Search Console and IndexNow.

The first two steps matter more than everything else combined. If the HTML is empty, nothing else on this list gets read.

Sources: Next.js useSearchParams docs, Next.js metadata docs, Google structured data guidelines, IndexNow.

Arsany

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

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:

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.

Sources

• Council of the EU backs Digital Omnibus changes (EU press release via EuropaWire)
• EU Council agrees 4-month cookie re-ask wait (PPC Land)
• Digital Omnibus and the GDPR: the Council mandate (Legal247)