Prospect Pages Don't Need a Login. They Need a Random Slug.

When we built the ops audit pipeline, we had to answer a question early: should the audit page be behind authentication?

The case for auth looks obvious. You're handing a prospect a document with estimates, assumptions, and details about their operation. Put it behind a login. Make it secure. That's what you do with sensitive documents.

We didn't do that. Every audit lives at a public URL. No login required.

What "Private" Actually Means Here

The data in an audit is not sensitive in the way financial records or medical data is. It's our analysis of a business's public-facing operation. Everything in it, we sourced from their website, their job posts, and their Google reviews. There's nothing in the document that the prospect would be harmed by if someone else read it.

What we actually want is narrower than privacy. We want two things:

1. The page should not rank in search results.
2. The page should not be trivially guessable.

That's a different problem than authentication. And it has a simpler solution.

Two Layers, No Login

The audit route is disallowed in robots.txt and every audit page carries a robots: { index: false, follow: false } metadata directive. Search engines that respect the standard won't crawl it and won't index it. The page will not appear in search results for the business name or anything else.

export async function generateMetadata({ params }: Props): Promise<Metadata> {
  return {
    title: `AI Operations Audit — ${audit.business}`,
    robots: { index: false, follow: false },
  };
}

The robots.ts file disallows the entire /audit/ directory:

rules: { userAgent: "*", allow: "/", disallow: "/audit/" },

The slug itself is {business-name}-{random-suffix}, like sample-business-x0x0. It's not guessable from the business name alone. Someone would have to have the link to access the page.

Why This Is Enough

Prospect-facing sales documents are not secrets. They're deliverables. We send the URL in an email. The prospect might forward it to a partner or a spouse. They might open it on their phone before the call. All of that is fine. We want them to read it. We want them to share it internally if that's what moves the deal forward.

What we don't want is the document surfacing in search results for the business's name, our name, or a phrase like "AI operations audit Hamilton County HVAC." That's what noindex handles. And we don't want a curious competitor or cold list-builder scraping an enumerable URL pattern. That's what the random suffix handles.

Authentication would solve both problems but introduce a third one: friction. A prospect getting a link to their audit and then hitting a login screen is an unnecessary obstacle at a point in the sales process where we want zero obstacles. They don't have an account. They'd have to create one. Some wouldn't bother.

The tradeoff Is Explicit

We're choosing light obscurity over hard access control. That's a deliberate tradeoff, not an oversight. It's appropriate for documents that contain our analysis of public data about someone else's business. It would not be appropriate for documents containing the prospect's actual internal data, financials, or anything they've shared with us in confidence.

If we were building a portal where prospects could upload their own data and see reports built from it, the calculus changes entirely. Lock that behind auth. But for a one-way deliverable we prepared from public sources, noindex and a random slug is the right level of control.

The URL is the access token. It doesn't expire, it doesn't require a password, and it works on the first tap from a phone without any friction.