Framer Protected Pages: How Auth Plugin's Shields Actually Work

• Shields and Protected Pages are the same feature. The setup wizard calls the step "Configure Shields." The dashboard sidebar calls the same section "Protected Pages." The pricing page says "Unlimited Shields." One feature, three names.
• A Shield is a URL pattern rule, a Path plus a Regex Pattern, that Auth Plugin's Shield script checks on every page load before any content renders.
• The Regex Pattern field auto-generates from your path if you leave it empty. /dashboard.* means the dashboard and every sub-page under it. /account (exact, no .*) means only that exact path.
• The Required Grants field is optional. Fill it with comma-separated grant names to restrict the page to users who hold those grants, not just any logged-in user.
• Shields do not activate until the site is published. Configuring a rule in the dashboard protects nothing until you publish.

Every Auth Plugin setup guide, including the full authentication guide, mentions Protected Pages as a step and moves on. What those guides skip is what the feature is actually doing: what the script checks, what the fields mean, and why a correctly configured Shield can still let someone through if you've misread the Regex Pattern. This post covers the mechanics. If you want the step-by-step configuration walkthrough, that's in the role-based access guide.

Nothing. They are the same feature referred to by different names depending on where you are in Auth Plugin.

In the setup wizard, Step 2 is labeled "Configure Shields." That's where you create your first URL pattern rules. In the plugin's dashboard sidebar after setup, the same section appears as "Protected Pages." On the pricing page, the feature is listed as "Unlimited Shields." On the homepage, it's described as "Protected Pages."

This inconsistency trips people up early. Someone who set up their pages during the wizard using the "Shields" label opens the dashboard later, sees "Protected Pages," and wonders if they're looking at a different feature or if something didn't save. They're the same thing. Any rule you create in one place is the same rule you see in the other. The setup wizard walkthrough shows what the Step 2 screen looks like if you want the visual confirmation.

From here, this post uses "Shield" and "Protected Page" interchangeably, the same way Auth Plugin does.

A Shield is a URL pattern rule. When you create one, you fill in two fields: a Path (like /dashboard) and a Regex Pattern (like /dashboard.*). Together they define which URLs the rule covers.

Auth Plugin injects two scripts into your Framer site as part of setup. The Shield script runs in headStart, which means it executes before any page content renders. The Relay script runs in bodyStart as a module and manages session state and token refresh. The Shield script is the one doing the checking: on every page load, it reads the current URL and tests it against every Shield rule you've created. If the URL matches a pattern and there is no valid session, the visitor is redirected to your Sign-In Page Path before they see anything on the page.

Because the Shield script runs in headStart, the check happens before HTML is painted. A visitor who doesn't qualify doesn't get a flash of the protected page and then a redirect. The redirect fires first.

Auth Plugin's suite includes 13 components, and Shields work alongside them rather than replacing them. Components like Sign In Form and Sign Up Form handle what happens at the sign-in page; Shields handle whether someone is allowed to reach any other page at all.

The Path field is the base route you want to protect. You enter the exact Framer path, like /dashboard, /account, or /members/content. This is what the Shield is targeting.

On its own, Path is not what the Shield script actually checks. The Regex Pattern field is what gets evaluated against the visitor's URL. Path is the starting point; Regex Pattern is the rule.

The Regex Pattern field is where the actual URL matching rule lives. If you leave it empty, Auth Plugin auto-generates it from the Path you entered, appending .* to the end. That's the default behavior and the reason most people never need to touch this field manually.

What /dashboard.* means in plain terms: it matches /dashboard and anything that starts with /dashboard — so /dashboard/settings, /dashboard/billing, /dashboard/anything-at-all are all covered by one rule.

In plain terms:

• /dashboard.* matches /dashboard, /dashboard/settings, /dashboard/billing, /dashboard/anything-at-all. One rule protects the dashboard and every sub-page under it.
• /account with no .* matches only /account exactly. /account/profile would not be protected by that rule. It would need its own Shield or the path would need to be set as /account.*.

That distinction matters more than it looks. A site with a dashboard at /dashboard and sub-pages at /dashboard/settings and /dashboard/billing is only fully covered if the pattern is /dashboard.*. Setting the Path to /dashboard and leaving Regex Pattern empty auto-generates /dashboard.*, so the default behavior covers sub-pages. But if someone has manually edited the Regex Pattern field to /dashboard (exact), the sub-pages are exposed.

If you're unsure what your current rules are matching, the Auth Page Paths guide covers a related concept — the redirect destination for unauthenticated visitors — and is worth reading alongside this.

Required Grants is an optional field on each Shield rule. Leave it empty and the Shield does one thing: it blocks anyone who isn't logged in and lets through anyone who is. Any authenticated user qualifies.

Fill it with a comma-separated list of grant names — like premium or premium, admin — and the rule changes. Now it's not enough to be logged in. The visitor's account also needs to hold the grants you've listed. A logged-in user who doesn't have those grants does not get through; the grant check triggers a redirect. Where exactly that redirect lands is not publicly documented, so this post won't claim a specific destination.

Required Grants is the field that enables tiered access at the page level. A page with Required Grants set to premium only lets through users whose accounts hold that grant — any logged-in user without it gets redirected. Leave Required Grants empty and any authenticated user can enter, regardless of their plan or role. The membership site guide goes deeper on the patterns for building tiered-access sites. The gated content guide covers section-level gating inside a page, which is a different tool from page-level Shields.

Worth being direct about what's not confirmed here: nothing checked for this post documents exactly what a "grant" is at a data level, where grants are assigned to users, or what the full redirect behavior is when a grant check fails. Required Grants is a real, visible field with confirmed behavior — it gates by grant ownership rather than just login state — and the specifics of grant management are beyond what this post can verify.

Here's the exact sequence when a visitor loads a URL that matches a Shield rule:

1. The visitor requests a URL.
2. The Shield script, running in headStart before content renders, reads the URL.
3. The script tests the URL against every Shield rule's Regex Pattern.
4. A match is found. The script checks for a valid session.
5. No valid session: the visitor is immediately redirected to the Sign-In Page Path set in Settings > General > Auth Page Paths. No page content is shown.
6. Valid session, no Required Grants on the rule: the page loads normally.
7. Valid session, Required Grants set, user holds the grants: the page loads normally.
8. Valid session, Required Grants set, user does not hold the grants: a redirect is triggered. The specific destination is not publicly documented.
9. No pattern match at all: the page loads normally regardless of session state.

Step 9 is the one that causes unexpected access. If a page isn't covered by any Shield rule, Auth Plugin doesn't protect it, even if it feels like it should be protected by proximity to another rule. Each URL that needs protection needs its own rule or needs to fall inside the .* range of an existing rule.

The redirect destination in step 5 is controlled by the Sign-In Page Path in Auth Page Paths, not by anything on the Shield rule itself. The Auth Page Paths guide covers that setting in full.

Yes. Every tier includes Unlimited Shields, confirmed on the pricing page. Basic (free, 100 identities, 1 site), Pro ($19/mo, 1,000 identities, 5 sites), and Scale ($49/mo, 10,000+ identities, unlimited sites) all include the same Unlimited Shields.

"Unlimited" means there is no cap on the number of URL pattern rules you can create. A single-page dashboard behind one rule and a hundred-page content library behind a hundred rules cost the same in terms of Shield rules: nothing extra either way.

The identity limit (100 on free, 1,000 on Pro) is a separate constraint. Shields are about URL rules, not about how many users can sign in. You can protect 100 pages on the free plan and still only accommodate 100 total signed-up users. Those are two different limits.

No. Auth Plugin's setup wizard completion screen confirms it directly: "Publish your site to activate shields."

Configuring a Shield rule in the dashboard — entering the path, setting the regex, saving it — none of that protects the page until you publish. The Shield script that runs on visitor page loads only picks up the rules that were live at the last publish. An unpublished rule exists in your dashboard but does nothing for anyone visiting the live site.

This is easy to miss during setup. The plugin's protected pages panel shows the rule as saved and active-looking. But the live site is still running the previously published version of the Shield script, which doesn't know about the new rule yet. Publish first, then verify in a private/incognito window. This applies to edits too: changing a regex pattern on an existing rule also requires a republish to take effect.

• Assuming "Shields" in the wizard and "Protected Pages" in the dashboard are different features. They're the same thing. One name in the wizard, one name in the sidebar.
• Setting the Regex Pattern to an exact path when sub-pages also need protection. /account only covers /account. Sub-pages like /account/profile need /account.* or their own separate rule.
• Expecting a Shield to activate before publishing. The rule is saved in the dashboard but has no effect on the live site until you publish.
• Leaving Required Grants empty and expecting it to restrict by plan. Empty means any authenticated user passes. Grant-based restrictions only apply when a grant name is actually entered.
• Confusing the identity limit with a Shields limit. Unlimited Shields means unlimited URL pattern rules. The identity limit (100 on free) is about signed-up users, not about how many pages you can protect.
• Not testing in an incognito window after publishing. The Framer editor preview is authenticated. Only a logged-out browser session confirms a Shield is actually working on the live site.

What's the difference between a Shield and a Protected Page?
Nothing. They are the same feature. "Shields" is the name used in the setup wizard and on the pricing page. "Protected Pages" is the name used in the dashboard sidebar. Same rules, same behavior, two labels.

What does the Regex Pattern field do?
It defines the actual URL matching rule the Shield script checks. Leave it empty and Auth Plugin auto-generates it by appending .* to your path. /dashboard.* matches /dashboard and everything under it. /account (no .*) matches only that exact path, not sub-pages.

What are Required Grants?
An optional comma-separated field on each Shield rule. Empty means any logged-in user can access the page. Fill it with grant names (like premium) and only users whose accounts hold those grants can pass. It's how tiered access — free vs paid members — is configured at the page level.

Do Shields work on the free plan?
Yes. All three tiers — Basic (free), Pro, and Scale — include Unlimited Shields. There's no cap on the number of URL pattern rules you can create on any plan.

Do Shields activate immediately after I configure them?
No. Auth Plugin's own setup wizard completion screen states: "Publish your site to activate shields." The rule has to be live on the published site before it protects anything.

What happens if a URL doesn't match any Shield rule?
The page loads normally, regardless of the visitor's login state. Shields only protect URLs that are covered by a matching pattern. A page with no rule is a public page as far as Auth Plugin is concerned.

Shields and Protected Pages are the same feature with different names depending on where in Auth Plugin you're looking. Each Shield is a URL pattern rule with a Regex Pattern that the Shield script checks in headStart before any page content renders. The default /path.* pattern covers a page and all its sub-pages. Required Grants narrows access beyond login state to specific grant holders. All 13 components are included on every plan, and Shields are unlimited on all tiers. None of it takes effect until you publish. For setup steps and role-based access patterns, the role-based access guide has the full walkthrough. For plan details, see the pricing page.