Setting Up Your First Captive Portal: Step-by-Step Guide

What a Captive Portal Actually Is

It helps to know what happens under the hood before touching any settings.

When a phone joins a network, the operating system quietly requests a known test page over plain HTTP. On a guest SSID with a portal, the access point intercepts that request and answers with a redirect to your login page. The phone notices and opens the page in a small built-in browser (on an iPhone it slides up as a sheet). Until the guest signs in, the access point blocks everything except the addresses on its pre-authentication list, which Omada calls Pre-Authentication Access and UniFi calls Pre-Authorization Access.

Two practical consequences. First, your portal's host has to be on that list or the page never loads; the walled garden guide lists what to add. Second, nobody can redirect an HTTPS request without a certificate warning, which is why the phone's own HTTP check does the work and why HTTPS redirection options on the controller cause more trouble than they solve.

What you configure in the portal itself is everything above that layer: the brand, the ask, the consent wording, and what happens after login.

Step 1: Brand Your Portal

The portal is often the first piece of your brand a guest sees on their phone. A blank white page with a generic form gives them no proof they are joining your network rather than someone else's, and people hesitate to type an email into a page they do not trust.

Include:

• Logo: at least 200px wide, with space around it
• Venue name: written out, not just the logo mark
• A short welcome line: "Welcome to [Venue name]. Stay connected while you're here." Something warm that confirms where they are
• Brand colours: button and accent colours that match your signage and menus

Keep the first screen uncluttered. Anything that is not needed to get online is something to scroll past.

Step 2: Choose Your Authentication Method

The main options, and their trade-offs:

Email form. The guest types an email address, and perhaps a first name. You get the data you need for follow up. It takes the most typing, so it suits venues where people sit down: cafés, hotels, lounges.

Social sign-in (Google, Facebook, Apple). One tap instead of typing, where it works. The catch is the built-in portal browser. Google has blocked its sign-in from embedded browsers since 2021, and the portal sheet on a phone behaves like one, so a Google button can fail exactly where you need it. If you offer social sign-in, keep an email form beside it and test it on real phones. VoqadoWiFi portals use an email form and do not offer social sign-in.

Click-through. The guest taps "Accept and connect" and gives nothing. No friction and no data. Useful where you only want terms accepted.

SMS code. The guest enters a phone number and types back a code. Phone numbers change less often than emails, but each code costs money to send and the extra step loses people. Marketing texts also need their own consent, separate from email.

For most seated venues, an email form with a clear, optional marketing choice is the sensible default.

Step 3: Write Your Consent Language

Operators get this wrong in both directions: no consent at all, or a wall of legal text that makes guests give up.

Keep two separate choices:

• Required: "I accept the WiFi terms of use." with a link to the terms
• Optional, unticked: "Yes, [Venue legal name] may email me about offers and events. I can unsubscribe at any time." with a link to your privacy notice

Do not pre-tick the marketing box and do not fold marketing into the WiFi terms. Under the GDPR, Recital 32 is explicit that pre-ticked boxes or inactivity do not count as consent, and a guest must be able to get online while saying no to marketing. The consent generator drafts both lines for you.

Place the text right beside the boxes, at a size people can read. The Security and Compliance lesson covers GDPR and CCPA in more depth. This is general information, not legal advice.

Step 4: Configure the Redirect

Where does the guest land after they connect? Many setups default to the venue homepage, which is rarely the best answer.

Send them somewhere that pays off the login:

A welcome page. "You're connected. Here's what's on today": specials, events, a menu highlight.

Your loyalty sign-up. If you run a loyalty scheme, this is a good moment to mention it. The guest has just shown some trust by logging in.

A same-day offer. "Thanks for connecting. Show this screen for a free refill today." Easy to count at the till.

Avoid: your homepage (too generic), your social profiles (sends the guest off into a feed), or a third-party booking site (you have just met them and are already sending them elsewhere).

Step 5: Test on Multiple Devices

Before going live, run the whole flow on:

• An iPhone, using the portal sheet that opens on its own
• An Android phone
• A laptop (Windows or Mac), for guests who work from your tables
• An older phone if you have one, because portal behaviour varies between operating system versions

Use a device that has never joined the network, with mobile data switched off, so it cannot fall back to 4G and hide a problem. Check that:

• The portal appears on its own, without the guest opening a browser
• It loads quickly on a weak signal at the far end of the room
• All text is readable without zooming
• Buttons are easy to tap; the WCAG guideline on target size asks for at least 44 by 44 CSS pixels
• Both checkboxes start unticked, and the form still connects you when only the terms box is ticked
• The device reaches the internet within a few seconds of submitting
• The redirect lands on the page you chose

Fifteen minutes of testing before launch saves an evening of troubleshooting with real guests.

Common Mistakes to Avoid

Asking for too much. Each extra field is one more reason to give up. An email, and maybe a first name, is enough. Birthday or postcode can wait for a later email.

No fallback for a failed social sign-in. If you offer it, always keep an email form as a backup.

Not knowing the authorisation period. Something decides how long a device stays online before it sees the portal again: the controller's own portal settings, or, with an external portal, the platform when it authorises the device. Too short and guests are asked again mid-visit; too long and you never see regulars come back. A published VoqadoWiFi portal uses 8 hours.

Not adding the portal to the pre-authentication list. The page spins and never loads. It is the most common reason a new portal fails on day one.

Going live with nothing after the login. The portal and what follows it are one experience. If someone opts in and hears nothing, the moment is wasted.

• 1Keep the portal light: phones open it in a small built-in browser, often on a weak signal
• 2Every extra field is one more reason to give up; ask for an email and little else on day one
• 3Make the venue unmistakable on the portal so guests trust that the network is really yours
• 4Accepting the WiFi terms and agreeing to marketing must be two separate choices, with the marketing box unticked
• 5Send guests somewhere useful after login, not to your homepage