Next.js Website Audit
Scanverra checks how your Next.js app renders - server, static, or client - and flags the next/image, Metadata API, and hydration issues that quietly cost you Core Web Vitals points.
What we check for Next.js
Six checks specific to how the App Router actually renders and ships code.
Rendering strategy per route
Whether a route is server-rendered, statically generated, or shipped as an empty shell that fills in client-side - and whether that choice fits the content. A marketing page rendered entirely on the client gives a crawler nothing to read on first paint.
next/image adoption
Raw <img> tags standing in for next/image, and images missing width/height (or fill) - the combination that causes layout shift as images pop in at their real dimensions.
Metadata API coverage
Per-route title, description, canonical tag, and Open Graph data versus one root metadata export reused - or missing - across every page.
Client vs. server component split
Unnecessary "use client" directives placed high in the component tree, which pull an entire subtree - and everything it imports - into the browser bundle when only a small interactive piece needed it.
Hydration mismatches
Server-rendered markup that doesn't match what React produces on the client, often from Date.now(), Math.random(), or a browser-only API called during render. These surface as console errors and dinged Best Practices scores.
Response-level security headers
Whether HSTS, X-Frame-Options, and similar headers are set globally - Next.js lets you do this once in next.config's headers() function instead of leaving every route to its defaults.
How it works
Three steps from URL to Next.js-specific fixes.
Paste your Next.js URL
No repo access and no build step - we scan the live, deployed page the same way a browser or crawler would.
We confirm the App Router signals
Response headers like x-powered-by: Next.js, /_next/static/ asset paths, and the __NEXT_DATA__ payload tell us we're looking at a Next.js app before the audit runs.
Get Next.js-specific fixes
Every issue is written against the framework you're actually running - next/image and Metadata API guidance, not generic advice.
Frequently asked questions
Does Scanverra know if I'm using the App Router or the Pages Router?
It detects that a site is running Next.js from response headers and build asset paths, then applies checks that work for either router - it doesn't need to distinguish the two to audit rendering, images, and metadata.
Will the audit catch a raw <img> tag I forgot to swap for next/image?
Yes. Unoptimized images and images missing width/height show up as Core Web Vitals and best-practices issues, the same way they would in a Lighthouse report.
Can it tell me if a specific page is rendering entirely on the client?
The audit inspects the HTML actually delivered on first load. A page with little or no content before JavaScript runs will show up as a content-visibility and SEO issue - which is usually a sign it's rendering client-side with nothing server-rendered underneath.
Does it check my Metadata API setup specifically?
It checks the output - title, meta description, canonical tag, and Open Graph data on the rendered page - regardless of whether you generated it with the Metadata API, a Head component, or hardcoded tags.
Will hydration errors show up in my report?
Console errors are part of the Best Practices score, and hydration mismatches are one of the more common ways they surface in a Next.js app.
Do I need to deploy before I can audit my site?
Yes - Scanverra scans a live, publicly reachable URL. A localhost address or a password-protected preview deployment won't work.
Other technology audits
See your Next.js Core Web Vitals in under a minute
Rendering, images, metadata, and hydration - scored and explained against the framework you actually shipped.
Run free audit