Most website audits only ever see the outside of the building.
The homepage. The pricing page. The blog. The public docs.
That's useful, but it is not the whole product.
If you've built anything even slightly app-like — especially with Cursor, Lovable, Bolt, v0, Replit, Claude Code, or any other AI-assisted workflow — the most important screens probably sit behind login.
That's where the real product lives.
And that's where the real problems hide.
The public site is the easy bit
A public marketing page is usually fairly simple.
It has copy, images, buttons, navigation, metadata, performance issues, accessibility issues, tracking pixels, and maybe a form or two.
Those things matter. PageLens AI audits them already.
But authenticated routes are different. They contain the screens where users actually trust you with something:
- their data
- their settings
- their payments
- their account state
- their private documents
- their dashboard
- their admin actions
- their project or customer records
The risk profile changes the moment a user signs in.
Public pages tell you whether the shopfront looks trustworthy. Authenticated pages tell you whether the product actually is.
Why AI-built apps are especially vulnerable here
AI coding tools are very good at generating a flow that works for the happy path.
Login page? Done.
Dashboard? Done.
Settings screen? Done.
Billing button? Done.
Admin route? Also done, apparently.
The danger is that "it works" is not the same as "it is safe, accessible, performant, and ready for a real user."
Authenticated areas are exactly where vibe-coded apps tend to accumulate quiet mistakes:
- A dashboard fetches too much user data because the generated API route returned the whole row.
- A settings form has no labels because it looked fine visually.
- A private page uses a layout shifty skeleton that makes the product feel broken.
- An admin link is hidden in the UI but the route itself is still reachable.
- A logged-in flow depends on local state that disappears on refresh.
- A payment or upgrade screen has unclear copy because nobody tested it as a new user.
- An authenticated API returns a stack trace because error handling was never tightened.
None of those issues are exotic.
They're boring.
But boring issues are what make users lose trust.
The problem with normal website scanners
Most scanners don't log in.
They crawl the public internet. If they hit /dashboard, /account, /settings, /billing, or /admin, they either see a sign-in page or they stop.
That means the audit misses the part of the app your actual customers use after they convert.
This is why a site can pass a public audit and still have a broken product experience.
Your homepage might be fast.
Your dashboard might be slow.
Your landing page might have perfect contrast.
Your settings page might have unreadable helper text.
Your public navigation might be clean.
Your authenticated mobile navigation might be impossible to use.
From a customer's point of view, the second set matters more.
What to check behind login
If you're reviewing an authenticated product manually, start with these areas.
1. Data exposure
Open your browser devtools and look at the network responses.
Are you returning fields the frontend doesn't need? Emails, internal IDs, roles, billing metadata, tokens, flags, notes, deleted records?
Prompt to try:
"Review my authenticated API routes and identify any responses that return more user data than the frontend needs. Flag anything that could expose PII, billing metadata, internal notes, roles, or security-sensitive fields."
2. Route protection
Don't just hide links. Test the URL directly.
If /admin, /settings, /billing, /api/admin/..., or /api/users/:id exists, it needs a server-side guard. Not a button condition. Not a client-side redirect. A real server-side permission check.
Prompt to try:
"Review my app's protected routes and API routes. Confirm that authentication and authorisation are enforced server-side, including direct URL access, role checks, and user ownership checks."
3. Logged-in UX
A lot of logged-in screens are built after the marketing site, under more time pressure, with less design attention.
That's how you end up with tiny tap targets, confusing empty states, missing loading states, and forms that only make sense to the person who built them.
Prompt to try:
"Review my logged-in product screens as a first-time customer. Find unclear copy, missing empty states, inaccessible controls, confusing navigation, and anything that would make a user unsure what to do next."
4. Performance where it hurts
Logged-in pages often do more work than public pages.
They load account data, reports, billing state, project lists, permissions, charts, recent activity, and background jobs.
That can be fine. Or it can quietly turn your app into a spinner museum.
Prompt to try:
"Review my authenticated pages for slow server queries, waterfalls, over-fetching, unnecessary client-side requests, and loading states that make the app feel broken."
5. Mobile reality
Your authenticated product probably gets tested on desktop first.
Your users will open it on a phone while doing something else.
If your mobile menu doesn't scroll, your sticky CTA covers the form, your table overflows the viewport, or your settings page needs horizontal panning, the product feels unfinished.
Prompt to try:
"Review my authenticated app on mobile. Identify navigation, layout, tap target, scrolling, sticky footer, modal, and table issues that would make the product hard to use on a phone."
How PageLens handles it
This is why we added authenticated route scanning to PageLens AI.
You can create an auth profile with a dedicated test account, set safe route boundaries, and ask PageLens to audit the pages your customers see after login.
That means the report can inspect things like:
- dashboards
- account settings
- billing and upgrade screens
- customer portals
- onboarding flows
- authenticated reports
- private tools
- role-specific pages
The point is not to bypass your security.
The point is to test your product the way a real user experiences it, using credentials you control, with explicit route scope so the scanner only visits what you allow.
If a page is private, it should still be good.
If a route is logged-in, it should still be accessible.
If a dashboard is where the customer gets value, it should be audited with the same seriousness as the homepage.
The dedicated test account matters
Do not use your personal admin account for this.
Create a safe test user.
Give it realistic but non-sensitive data.
Make sure it can see the product states you care about.
Then audit that.
This is the same reason teams use staging customers, seed data, and demo workspaces. You want enough realism to catch product issues without handing a scanner access to anything it doesn't need.
Authenticated scanning is powerful, so the setup needs to be deliberate.
That's a feature, not friction.
If you take one thing from this
Your public site is not your whole product.
If users log in, the logged-in experience is where trust is either reinforced or lost.
That's true for SaaS dashboards.
It's true for client portals.
It's true for AI tools.
It's true for anything with accounts, payments, reports, settings, or private data.
So don't only audit the pages Google can crawl.
Audit the pages your customers actually use.
If you want to try it, PageLens AI supports authenticated route scans with route boundaries and dedicated test credentials, so you can review the private parts of your app before your users find the problems for you.
— Richard