Your homepage is a login wall: why a great app nobody can find is still invisible

There's a specific way for a good software product to be completely invisible, and it's more common than you'd think among indie SaaS, internal tools that went public, and weekend builds that found real users. You ship the app. The app works. People who have an account love it. And the homepage — the one URL the whole world sees first — is a log-in form.

That's it. Email, password, a "sign up" tab, maybe a logo. No explanation of what the thing does, who it's for, what it costs, or why anyone should make an account. The product lives behind the wall, and the wall is the only thing the public internet can see.

I added a login-wall readiness check to the Mega Analyzer because this pattern keeps showing up, and none of the other vertical checks catch it. The SaaS-readiness check assumes a marketing site already exists and grades the schema on it. But if the homepage is just an auth form, there's no marketing site to grade — and that absence is the single most expensive problem the site has.

Why a login wall is fatal for discovery

Search engines and AI answer engines can only recommend what they can read. When the homepage is an auth form, here's what a crawler — Googlebot, GPTBot, ClaudeBot, PerplexityBot — actually sees:

• A page title, if you set one.
• Twelve or fifteen words: a brand name, a tagline, the words "log in" and "sign up."
• No description of the product, no features, no pricing, no FAQ, no proof.
• Usually no structured data at all.

You cannot rank for "how do I [the thing your product does]" when the page has never said what the thing is. You cannot be the answer ChatGPT gives when someone asks for "a tool that does X" because there is no readable claim that you do X. The product might be the best in its category; to a machine reading the front door, it is a password prompt.

It gets worse for products that grow through invitations. A huge share of these apps spread coach-to-coach, team-to-team, friend-to-friend, through invite emails. Those emails carry a link back to… the login wall. So even your warmest traffic — someone a trusted colleague personally invited — lands on a bare auth form with no reassurance about what they're signing into. And the email itself, if the sending domain has no SPF, DKIM, and DMARC, has a good chance of never reaching the inbox at all. The growth loop leaks at both ends.

The check, and what it flags

The login-wall check fires only when the homepage is genuinely a wall: it's the root URL, it has an actual auth form (a password field, or paired log-in / sign-up forms), it has almost no visible words, only a handful of links, and none of the usual marketing-page words (pricing, features, how it works, about, blog). That combination is specific enough that a normal marketing site with a "Log in" button in the corner won't trip it, and a /login subpage won't either — only a homepage that is the login.

When it fires, it walks through the whole chain of consequences:

1. The keystone: there's no public surface to index or cite. Build a real marketing site in front of the app and move the app itself behind /app (or an app. subdomain). Home, how-it-works, features, pricing, FAQ, about, contact. Everything below depends on this existing first.
2. No entity graph. Once a public page exists, emit an Organization node, a SoftwareApplication node (the single most on-type signal that tells an AI engine there's a product to recommend, not just a company), and a WebSite node — all tied together by @id.
3. No share preview. A missing meta description, Open Graph tags, canonical, and favicon mean every shared link and every invite renders as a bare URL with no title, image, or icon. It looks broken before anyone clicks.
4. The email loop. If the app sends invite or reset email, deliverability is the growth engine. Verify SPF, DKIM, and DMARC with the DNS + Email audit.
5. Security headers on a credential form. A page that collects a password needs HSTS, a CSP, X-Frame-Options, X-Content-Type-Options, and a Referrer-Policy. A login with no X-Frame-Options is clickjacking-exploitable. Check it with the Mega Security Analyzer.
6. Auth-flow accessibility. Render login errors in a role="alert" / aria-live container so screen-reader users actually hear "wrong password," add a <main> landmark, and label every input.

The check ships a copy-ready fix prompt with all six, so you can hand the whole list to your AI coding assistant and work through it.

The fix is an afternoon, not a rebuild

Here's the good news: you don't have to touch the app. The app is fine — people who get in already like it. You're adding a front, not rebuilding the back.

A static marketing page in front of an app is a few hours of work. One HTML page (or a handful) that says what the product is, shows a screenshot, names the audience, states the price, answers the five questions every prospective user asks, and has one obvious "create an account" button that points at the existing sign-up. Put the schema in the <head>, set the Open Graph tags, add a favicon, and ship it. Then point the app at /app so the homepage is free to do its real job: convince a stranger.

Once that page exists, every other piece of digital-presence advice you've ever read suddenly has somewhere to live. sameAs links to your profiles. A FAQ marked up as FAQPage. An llms.txt. A blog. Per-state or per-use-case landing pages. None of it was possible while the front door was a password prompt, and all of it is possible the moment a public page exists. The login wall isn't one problem among many — it's the gate that was holding all the other fixes hostage.

If you're building your own corner of the web from scratch and want the soup-to-nuts version of getting a product found, not just shipped, that's exactly the arc I wrote The $97 Launch around — the marketing surface, the entity graph, the distribution, in the order that actually compounds.

Related reading

• SaaS / AI-product readiness: the schema that makes an AI recommend your product
• Email infrastructure for small business: SPF, DKIM, DMARC without the jargon
• Modern security headers, and why a login page needs them most
• Entity anchors and the knowledge graph: how AI decides who you are
• Cross-domain entity consistency: keeping your name the same everywhere

Fact-check notes and sources

• Google Business Profile eligibility (relevant because online-only apps often ask whether a GBP would help them get found — it won't, and they're not eligible): Google requires a business to "make in-person contact with customers during its stated hours." Online-only businesses with no location customers can visit are ineligible. Source: Google Business Profile eligibility guidelines.
• DMARC / SPF / DKIM as the determinants of whether invite email inboxes: see RFC 7489 (DMARC) and the M3AAWG sender best practices.
• FTC rule on reviews and testimonials (16 CFR Part 465, effective Oct 21, 2024): any rating or testimonial you mark up in schema must be genuine and substantiable. Source: FTC final rule on consumer reviews.
• X-Frame-Options / clickjacking on credential forms: see OWASP Clickjacking Defense Cheat Sheet.

This post is informational, not legal or security-consulting advice. It describes a general anti-pattern; any resemblance to a specific site is incidental. No third party is named or implied.