A Next.js website audit is a paid, time-boxed review of a live site that ends in a ranked list of fixes, each with an effort estimate and an expected outcome. If you already own a Next.js site backed by Sanity and something feels off (slow pages, editors complaining, rankings drifting), an audit is the cheapest way to turn a vague worry into a plan. This post explains what you should get for your money, what real findings look like, and how to decide afterwards whether it was worth it.
What a Next.js website audit should cover
A good audit has a defined scope that you can read before paying. For a Sanity and Next.js site I split it into five areas.
Field performance. Not just a Lighthouse run on my laptop. I look at real-user Core Web Vitals (LCP, INP, CLS) from Search Console or your analytics, then lab-test the templates that matter: home page, a landing page, a long article, a listing page. If you have no field data yet, that is itself a finding. The Core Web Vitals monitoring setup is usually the first thing I recommend.
Rendering and caching. Which routes are static, which are dynamic, and whether that matches what the content actually needs. Many sites are accidentally dynamic because one component reads cookies or headers, which turns a page that could be cached into one that hits the origin and Sanity on every request.
Sanity data layer. GROQ queries, schema shape, and how pages fetch content. I check for over-fetching, reference chains that cause waterfalls, and images served without the metadata needed to prevent layout shift. Patterns here are covered in structuring Sanity schemas to avoid query waterfalls.
Studio and editor experience. I open the Studio the way an editor would. Cluttered document lists, unclear field names, missing validation, and drafts mixed in with live content all cost your team time every week.
SEO plumbing. Metadata, canonical URLs, sitemap, robots, structured data, redirects, and whether the rendered HTML contains the content a crawler needs.
A scope that also promises security pen-testing, legal compliance, and a full rewrite estimate for a few hundred dollars is overselling. Narrow and deep beats broad and shallow.
Sample findings from audits like this
I will not quote results from specific clients. What I can describe is the kind of thing that shows up again and again on sites like this:
- The hero image is the LCP element and is lazy-loaded or missing a priority hint. Cheap to fix, often the single biggest LCP gain. See fixing LCP on image-heavy pages.
- Every page fetches whole documents. Queries return full Portable Text bodies and every field on referenced documents when the template needs a title and a slug. The payload grows with the content, so the site gets slower as editors do their job.
- A client component wraps the whole page. One top-level use client directive pulls a large tree into the JavaScript bundle. Splitting it is usually an afternoon, and the bundle size analysis post shows how to find it.
- Revalidation is all or nothing. Either nothing refreshes until the next deploy, or every publish invalidates the entire site. Tag-based revalidation from a Sanity webhook fixes both.
- The Studio has document types nobody uses. Old experiments sit in the sidebar and confuse new editors.
- Structured data is present but wrong. JSON-LD that references a logo URL that now returns 404, or an Article type on pages that are not articles.
- Redirects live in three places. Some in the CMS, some in config, some on the host, with chains between them.
None of these are exotic. That is the point: most audit value comes from finding ordinary problems quickly and putting them in the right order.
How the ranked fix list works
The deliverable that matters is the ranked list. Each row should have four things: what is wrong, why it matters to the business, roughly how long the fix takes, and how we will verify it worked. Here is the shape I use:
| Rank | Finding | Impact | Effort | Verify with |
|---|---|---|---|---|
| 1 | Hero image not prioritised on landing templates | High (LCP) | Under 2 hours | Field LCP trend over 28 days |
| 2 | Home page query returns full documents | High (TTFB, payload) | Half a day | Response size and server timing |
| 3 | Top-level client wrapper on article pages | Medium (INP, bundle) | 1 day | Bundle analyzer, INP trace |
| 4 | Webhook revalidates entire site on every publish | Medium (cost, stale pages) | Half a day | Cache hit rate after publish |
| 5 | Unused document types in Studio | Low (editor time) | 2 hours | Editor walkthrough |
Ranking is by impact divided by effort, not by how alarming a Lighthouse score looks. A red metric that needs a two-week rebuild goes below a yellow one that needs an hour.
You can use the list in three ways. Hand the whole thing to your in-house developer and have them work top to bottom. Hire me to fix the top five. Or take it to another developer for a competing quote, which is a perfectly reasonable thing to do. A good audit is portable; if you cannot use it without the person who wrote it, it was a sales funnel.
How to judge whether the audit was worth it
After the call, ask yourself these questions.
Could someone else act on it? If a competent developer can open the document and start work without a meeting, it passed.
Did it say what not to fix? Honest audits include a short list of things that look bad in a tool but do not matter for your traffic or goals. If every finding is urgent, nothing was prioritised.
Did it tie to money or rankings? A fix for INP on a page with no organic traffic is lower priority than a fix for LCP on your best landing page. The post on what fast pages are worth helps frame this.
Were the claims checkable? Each finding should name the page, the file or query, and the measurement. Vague statements like "improve image optimisation" are not findings.
Did you learn something about your own site? Even if you fix nothing, you should now know where the time goes and which parts of the codebase are risky.
Red flags: the report is mostly screenshots of automated tools, the author cannot explain a finding when asked, the audit recommends a full rebuild without ruling out cheaper fixes, or the price is tied to a retainer you must sign first.
If the top fixes are small, the audit may pay for itself within a month through faster pages and fewer editor complaints. If the answer really is a larger change, such as a migration or an upgrade, you at least have a scoped number instead of a guess.
What to prepare before you buy one
Give the auditor read access to the repository, the Vercel project, the Sanity project, and Search Console. Decide in advance who will receive the findings and who can approve work. Write down your top three concerns in plain language, such as "our pricing page is slow on mobile" or "editors avoid creating case studies." A brief like that keeps the audit pointed at outcomes. If you are unsure how to frame it, the guide on writing a project brief for a Next.js developer applies here too.
If your site is already visibly slow and you want to diagnose it yourself first, start with why a Sanity website is slow and what a fix costs.
Work I do
A performance and Sanity audit with a ranked fix list is a fixed-price package I offer, starting from $800. Details are on the services page.
Top comments (0)