If you run a gated site, pw domain seo is the problem you keep running into: Search Console shows a handful of impressions, a mediocre average position, and no movement no matter what you publish. A typical pattern looks like this. Five impressions, average position 16.2, over a month. That is not a penalty. It is Googlebot standing at a locked door, reading a login form, and leaving.
This post walks through what actually happens when a crawler hits HTTP auth or a login wall, and gives you three fixes you can ship this week. You will also see how to run the audit on autopilot with a CLI and an AI agent, so you stop re-checking the same five impressions by hand.
PUBLIC CRAWLER PATH PRIVATE MEMBER PATH
------------------ --------------------
Googlebot Googlebot
| |
v v
/ (public page) /members/lesson-3
| |
v v
200 OK + indexable HTTP 401 / login form
| |
v v
Indexed, can rank Not indexed. No snippet.
| |
v v
links down to -------------------> humans only (cookie/session)
Rule: rank the doorway, hide the room.What Is a PW Domain and Why It Breaks SEO
A PW domain is a site where the content sits behind a password gate. Sometimes that is server level HTTP authentication. Sometimes it is a JavaScript login form that swaps the page after the user authenticates. Sometimes it is a course platform subdomain with every lesson locked.
All three break SEO the same way. The crawler never gets the content, so there is nothing to index and nothing to rank. The page exists for logged-in humans and does not exist for search.
That is fine if you never wanted it ranked. It becomes a problem when you write about your gated topics in public, publish the titles on your home page, and then wonder why the gated version of those pages never shows up. You have done the work twice: once for members, once for nobody.
The underlying rule is simple and worth taping to the wall. Search engines rank pages they can read. Everything below is a variation on that one sentence.
Why Google Shows 0 Rankings for Password-Protected Pages
Look at the numbers again. Five impressions, position 16.2. If your gated pages were treated as normal pages, you would expect hundreds of impressions on brand terms alone. Five means Google is only showing a thin slice of your site, almost certainly the public shell pages: the login screen, the marketing home page, maybe a blog index.
Three things happen when a crawler meets a login wall.
- The fetch returns an authentication challenge or a page that is mostly a form. Google may index the login page itself, but that page has nothing to rank for except your brand name.
- Internal links behind the wall are invisible. Your members area stops passing any signal to anything.
- Any content that only exists after authentication is treated as if it does not exist.
Position 16.2 is a telling detail. Anything in the teens usually means low relevance or thin content, not a manual action. Those five impressions were probably your brand queries hitting a page that cannot answer them properly. That is a content visibility problem, not a penalty problem. Fixing it means giving search engines something better to read, not filing a reconsideration request.
How Googlebot Handles HTTP Auth and Login Walls
HTTP auth and a JavaScript login wall are different mechanisms with the same outcome.
With HTTP auth, the server returns a 401 and the crawler sees a challenge it cannot answer. It gets no body content.
With a login form, the crawler gets HTML, but it is a page made of inputs and a submit button. There is no article, no course lesson, no member directory. There is nothing to return in a search result.
Session cookies make this worse in a subtle way. Even if you handed a crawler credentials, its session would not persist across the many requests needed to explore a member area the way a human does. Google is not sitting there logged into your site.
So the practical question is not “how do I get Google inside my members area?” It is “what public page can I build that represents this gated content honestly?” That reframing is the whole game.
Fix 1: Move Gated Content Behind a Public Landing Page
Build a public page for every gated asset you want to rank. The page sits in front of the gate. It describes the lesson, the template, the cohort, the download, whatever the thing is, in full enough detail that it answers a real search query. Then it offers a single action: sign in, join, or buy.
Concretely, for a gated lesson on onboarding cold email:
- Public landing page: “How to write a cold email sequence that books 5 calls a week.” Full explanation, the framework, two examples. No gate.
- Gated asset: the swipe file of 40 tested sequences, plus the video walkthrough. Members only.
- Bridge: one call to action on the public page pointing at the swipe file.
Now Google has something to index and rank for a term you actually want. You get the traffic. The gate stays closed. Your members get the deeper asset, which is exactly the thing that should live behind a login.
This works because search intent splits. Someone searching “cold email sequence framework” wants to understand the idea and will happily read it in public. Someone who wants to copy 40 finished sequences is a much better fit for membership, and they will convert from the public page.
If you are building these public pages with an AI agent, point it at the gated URL structure first so it knows what already exists. The WordPress SEO agent workflow covers connecting a site and having the agent produce drafts rather than publish straight to live. Drafts by default is the right setting for anything you gate, since a wrong slug on a public page costs you real rankings.
Fix 2: Whitelist Crawlers Without Exposing Private Pages
The instinct here is to hand Googlebot credentials. Do not. Google does not log into your site, sessions do not persist the way you would need, and any credential you paste into a config file eventually leaks.
The safe pattern is a separate public surface on the same domain, not a hole punched through the gate.
- Serve public landing pages from a path like
/guides/that has no auth at all. - Keep
/members/fully gated. Do not whitelist it for anyone. - Link from each public guide to the matching gated asset with a normal link. Humans click it and hit the login. Crawlers follow it, get the gate, and treat it as a dead end, which is correct.
- Never expose member names, emails, revenue numbers, or community posts in the public page markup. Not in headings, not in alt text, not in structured data.
That last point matters more than people expect. If you build course landing pages by dumping lesson titles from your database into the HTML, you can leak the shape of the private content even if the body is gated. Keep the public page a hand-written or AI-drafted description of the offer, not a database export.
Same rule applies to community platforms. If you run a Skool group with paid tiers, the coaches and consultants workflow is a useful reference for keeping member-facing work separate from public marketing work.
Fix 3: Use Robots.txt and Sitemaps Correctly on PW Domains
Two small technical jobs make the split clean.
Robots.txt. Block the private paths and allow the public ones. A minimal version looks like this:
User-agent: *
Allow: /guides/
Disallow: /members/
Disallow: /account/
Disallow: /checkout/
Sitemap: https://www.example.com/sitemap.xmlDo not block your CSS and JavaScript. Google needs those to render the public guides. And do not use robots.txt as your security. It is a request, not a wall. Real gating is auth plus server checks.
Sitemaps. List only public, indexable URLs. Every gated URL you put in a sitemap is a wasted crawl and a confusing signal. If you are on WordPress, most SEO plugins generate the sitemap for you, but check that your membership plugin is not injecting gated URLs into it. This is one of the most common causes of a PW domain showing impressions with no movement.
Quick sanity check anyone can run: open your sitemap and open each URL in a private browser window. If you see a login form instead of content, that URL should not be in the sitemap.
How to Rank for PW Domain SEO Terms You Already Own
Here is the part most gated businesses miss. You probably already have the vocabulary. Your members use specific phrases for your methods, your templates have names, your community threads are full of questions phrased in the exact language people search.
Mine that. Pull the recurring questions and terms out of your member area and turn each one into a public landing page from Fix 1. You are not inventing topics. You are exposing the topics you have already validated internally.
On the Creator OS side, the hosted MCP server exposes a set of named tools an AI agent can call, including get_daily_metrics, get_follower_stats, and get_best_time_to_post for the accounts you run. The point is not to automate your SEO strategy. It is to keep the publishing and analytics layer in one place while you build the public content that actually ranks. If you want a mental model for how the tool layer stays stable while you change prompts, the MCP server reliability notes are worth a read.
For video assets that live behind the gate, the same split applies. Post the public teaser, gate the full walkthrough. The TikTok posting API explainer covers what the publishing layer handles for you, and the open source captions editor is useful if you want to produce that teaser yourself instead of paying for a tool.
Track GSC Impressions and Positions for Gated Pages
You cannot fix a number you are not watching. Set up a simple monthly check.
- Search Console, Performance report, filter by page group. Compare public guides against everything else.
- Watch average position in the low teens specifically. That band usually means the page exists but does not answer the query yet.
- Watch impressions. Five impressions on a whole domain means Google has almost nothing to show. That is the real alarm, not the position.
- Track query level, not just page level. Gated domains often rank for brand terms and nothing else, which is a clear sign the public surface is too thin.
Write down two numbers each month: total impressions, and impressions on public guide pages. If public guide impressions are flat while you publish, the pages are not earning their place yet. Rewrite the weakest one before writing a new one.
Automate PW Domain SEO Audits With an AI Agent
The audit above is mostly repetitive work, which is exactly what an agent is good at. Creator OS ships a CLI (@creatoros/cli) and 14 installable agent skills, so you can have an agent run the checks on a schedule instead of opening tabs.
Start by installing the skills:
npx @creatoros/cli@latest initThat gives you skills including analytics, blog, and kairos-dashboard. Then a monthly loop looks like this:
creatoros analytics:daily --from 2026-01-01 --to 2026-01-31
creatoros analytics:posts --sortBy engagement --limit 20
creatoros blog:list --limit 20The first two pull daily account metrics and per post performance across connected platforms, so you can see whether the public guides you published are getting pushed. The third lists your blog articles so the agent can compare what you published against what you planned.
You can also drive this over MCP. Add the hosted server to Claude Code:
claude mcp add --transport http creatoros https://mcp.creatoros.ca/mcp \
--header "Authorization: Bearer cos_live_..."Then ask the agent to list recent posts, pull analytics, and draft a public landing page for any gated asset you have not yet exposed. Read only connections are supported, and destructive tools are marked so your AI app asks before doing anything irreversible. Connect it in Claude from Settings, Connectors, Add custom connector, or in ChatGPT as a connector in developer mode. Full setup lives at the MCP docs.
If you want the harness rather than the plumbing, Social Agents is the open source agent harness that runs your accounts on Creator OS. Start it with npm start creatoros social-agents. It interviews you about your brand, then posts, replies, and reports from a local dashboard. Bring your own model. The Social Agents documentation has the details, and you can watch the walkthroughs on the KevBuildsApps YouTube channel.
One caution. Do not let an agent publish public pages unattended on a domain with a gate. The failure mode is bad slugs and duplicated titles going live, and unlike a social post, a wrong URL is expensive to undo. Keep it in draft.
Get Started With Creator OS
Creator OS puts publishing, scheduling, replies, member community work, a WordPress blog, and analytics in one place. It runs from the web app, the iOS app, a REST API, the CLI, and a hosted MCP server for Claude, ChatGPT, Claude Code, Cursor, Codex, Windsurf, and VS Code. API keys, the MCP server, the CLI, and the agent skills are included in every plan.
The Creator plan is $19.99/month or $59.99/year, with up to 8 connected accounts: 7 socials plus Skool. Agency plans cover 5 sets of socials for $49/month or $399/year, and 10 sets for $99/month or $599/year. If you are building public SEO content alongside gated video, the launch video for the open source editing tools is at youtu.be/-QBJH_PK3pY.
Make a free account at creatoros.ca/sign-up. Then connect your accounts, install the skills, and draft the first public landing page for the gated asset your members already ask about most.