Auth Plugin's Auth Page Paths: How Global Redirects Actually Work

• Sign-In Page Path and Sign-Up Page Path live in Auth Plugin Settings, under the General tab, in a section called Auth Page Paths, confirmed directly on a live Framer instance's properties panel.
• These two fields are global and site-wide. They tell Auth Plugin which Framer pages actually carry your sign-in and sign-up forms, so it knows where to send a visitor who is not signed in.
• Sign-In Page Path's own helper text is explicit that it must not be the home page (/).
• That is a different setting from any single component's own Redirect Path, like Reset Password Form's Redirect Path, which only controls where that one form sends someone after a successful action.
• Getting the global Sign-In Page Path wrong, or leaving it pointed at the wrong page, can break redirects across every protected page on the site, not just one form.

Most Auth Plugin setup guides walk through dropping a Sign In Form and a Sign Up Form onto pages and calling it done. What those guides tend to skip is a pair of fields buried in Settings that quietly control something bigger: where the whole site sends someone who is not signed in. Get those two fields wrong and every protected page can misfire, even if each form component looks correctly configured on its own page.

This post covers what Sign-In Page Path and Sign-Up Page Path actually do, how to set them correctly, and the distinction that trips people up: confusing a global, site-wide setting with a single component's own Redirect Path. If you have not gone through the basics yet, start with the setup guide first.

Auth Page Paths is a section inside Auth Plugin's Settings, under the General tab, containing two fields: Sign-In Page Path and Sign-Up Page Path.

The section's own description reads: "Set the Framer page paths where your login and signup forms are placed. Users will be redirected here when they need to sign in." In plain terms, you are not building a sign-in page here. You are telling Auth Plugin where the sign-in and sign-up pages you already built actually live, so the plugin can point to them from anywhere else on the site.

They matter because Auth Plugin has no other way to know where your login and signup pages are. Framer does not enforce a fixed route naming convention, so a site could carry its sign-in form on /sign-in, /login, /account/sign-in, or anything else. Auth Page Paths is how you tell Auth Plugin which one is real for your site.

That matters most for a visitor who is not signed in. When Auth Plugin needs to send someone to sign in, it uses whatever path is set here. If the path is wrong, empty, or points at a page without a Sign In Form on it, the redirect sends people somewhere useless.

Set Sign-In Page Path to the exact Framer path of the page carrying your Sign In Form, and make sure that path is not the home page. The field's helper text states this directly: it "must NOT be the home page (/)."

That restriction is worth taking seriously rather than working around. A sign-in redirect that points back at the home page risks a loop on any site where the home page itself is ever gated or where other logic expects the home page to be public. Put the Sign In Form on its own dedicated path, something like /sign-in or /login, and point this field at that exact path.

Set Sign-Up Page Path to the exact Framer path of the page carrying your Sign Up Form. The field's own helper text gives two concrete examples: "e.g. /signup, /register, the page with your sign-up form."

Unlike Sign-In Page Path, there is no documented restriction against using the home page here. Still, the same practical logic applies: put Sign Up Form on its own path and point this field at exactly that path. If the two paths drift out of sync with where the forms actually live, such as after renaming a page during a redesign, this field needs to be updated to match. Nothing updates it automatically.

Auth Page Paths and a component's Redirect Path solve two different problems, even though both sound like "where does this send someone."

Sign-In Page Path and Sign-Up Page Path are global settings, one value each, set once in Settings, and they control where an unauthenticated visitor gets sent to find your login and signup forms in the first place.

A component's own Redirect Path is local to that one component instance, and it controls what happens after a successful action on that specific form. Reset Password Form's Redirect Path is a clear example: it defaults to /sign-in and sends a visitor back to sign in only after they successfully complete a password reset on that particular form. It has nothing to do with where Auth Plugin sends someone who shows up unauthenticated elsewhere on the site.

Auth Plugin's Sign In Form and Sign Up Form components document a similar post-action redirect property, labeled Redirect URL in the docs, defaulting to / and /welcome respectively. As with other components on this site, your live panel may not match the docs wording exactly, so check your own instance. Either way, that property is still local to the component, not where Auth Plugin sends someone who is not signed in yet.

Put simply: Auth Page Paths answers "where do the forms live." Component Redirect Path properties answer "where does this one form send someone next." Misconfiguring one does not fix a problem with the other.

Protected Pages is the feature that gates a page and sends unauthenticated visitors somewhere else before the page content loads. Auth Plugin's own documentation on Protected Pages describes it matching the current URL against a regex pattern via an injected script checked on every page load, then redirecting if there is no valid session.

The Auth Page Paths description says visitors get redirected there "when they need to sign in," the same moment Protected Pages triggers a redirect for a gated page. That makes Sign-In Page Path the setting most directly responsible for where that redirect lands. Treat that as the field's confirmed core job, Auth Plugin may reuse it for other cases too, such as an expired session elsewhere on the site, but that's not spelled out publicly, so don't treat this as an exhaustive list.

Auth Plugin doesn't publish specifics on edge cases like a blank Sign-In Page Path or exactly how fast a change propagates, so treat testing as standard practice rather than a one-time setup step: check the redirect in an incognito window after any change to this field, the same way you'd verify any critical path after touching a global setting.

• Leaving Sign-In Page Path pointed at the wrong page after a redesign. If the Sign In Form moves and this field is not updated to match, every protected page's redirect lands somewhere without a working sign-in form.
• Setting Sign-In Page Path to the home page. The helper text explicitly rules this out, and it is a likely source of redirect loops if the home page is ever gated.
• Confusing this setting with a component's Redirect Path. They are not interchangeable. Fixing a broken post-login redirect on one form does nothing for a site-wide sign-in redirect problem, and vice versa.
• Relying only on docs.authplugin.com for this setting. The public docs site doesn't cover every field in the Settings panel yet, Auth Page Paths included, so treat your own live panel as the reference here rather than searching the docs for it.

Where exactly do I find Sign-In Page Path and Sign-Up Page Path?
In Auth Plugin's Settings, under the General tab, in a section labeled Auth Page Paths.

Is Sign-In Page Path the same as a component's Redirect Path?
No. Sign-In Page Path is a single global setting that tells Auth Plugin where your sign-in form lives, for redirecting unauthenticated visitors. A component's Redirect Path, like the one on Reset Password Form, only controls where that specific form sends someone after a successful action on it.

Can Sign-In Page Path be the home page?
No. The field's helper text explicitly states it must not be the home page (/).

Does Sign-Up Page Path have the same home page restriction?
No such restriction is stated for it. Its helper text gives examples like /signup and /register, without the home-page warning that Sign-In Page Path's helper text includes.

What happens to redirects if I never set these fields, or set them wrong?
A wrong or missing value here is a good first thing to check if sign-in redirects seem broken, since Auth Page Paths controls exactly that. The precise failure behavior isn't spelled out publicly, so if it turns out not to be the cause, the setup errors post covers other causes to rule out.

Sign-In Page Path and Sign-Up Page Path sit in Auth Plugin Settings, under the General tab, inside an Auth Page Paths section. They are global, site-wide fields that tell Auth Plugin which pages actually carry your sign-in and sign-up forms, so it knows where to send a visitor who needs to sign in, including anyone hitting a protected page while logged out. Sign-In Page Path cannot be the home page. That is a completely different setting from a component's own Redirect Path, such as Reset Password Form's Redirect Path, which only decides where that one form sends someone after a successful action, not where the rest of the site sends an unauthenticated visitor. Mixing these two up is a common way to end up with redirects that look broken on one page while the actual misconfiguration is a single global field in Settings. When in doubt, check the admin dashboard and Settings panel directly rather than assuming either setting behaves like the other.