Built with Next.js
Check a Next.js site
Next.js gives you a clear server and client boundary, and almost every serious problem in a Next.js deployment comes from that boundary being crossed by accident rather than from the framework itself.
Free website audit — no account
Find out what your website is giving away.
Paste your address. In about a minute you will see everything that is exposed, broken, or quietly costing you customers — and the exact fix for each one.
Not ready
Two things here need fixing before anyone visits.
Your payment password is visible to anyone
It is sitting in your website’s code, where any visitor can read it.
A settings file can be downloaded by anyone
It contains the keys to your database.
Your security certificate expires in 9 days
Visitors will see a red warning page when it does.
Google is told not to show 4 of your pages
Almost certainly a mistake left over from building the site.
7 pictures have no description
People using a screen reader cannot tell what they are.
What tends to go wrong on Next.js
None of this means you did something careless. These are the defaults.
NEXT_PUBLIC_ on something secret
That prefix inlines the value into the browser bundle at build time, by design. Adding it to silence an undefined-variable error publishes the secret and makes the error go away, which is the worst possible combination.
No security headers
Nothing is set by default. Until you add a headers() block, your pages can be framed by anyone and have no policy limiting which scripts may run.
Source maps served in production
Enabled to debug a deployment and left on, they let anyone reconstruct your original source.
Route handlers without authorisation
A handler under app/api is public unless you check the session inside it. There is no implicit protection.
Every fix is written for Cursor
Findings do not stop at telling you something is wrong. Each one comes with the change to make, in five versions — including one you can paste straight into Cursor and one written with no jargon at all.