The idea in one sentence

A Web URL button is a door in your app that opens a web page. Everything else about MAM Suite turns your WordPress content into native mobile screens; a Web URL button does the opposite — it hands a screen back to the web by pointing it at a URL you supply.

That’s the whole concept, but it’s worth sitting with before you reach for this button. Showing a web page is the most flexible thing your app can do — and the most likely to feel un-app-like if you lean on it too often.

Why this content type exists

MAM Suite is built on a simple promise: you author content in WordPress, and the app renders it as native mobile UI. A WordPress page becomes a real app screen, a post category becomes a scrollable native list, a contact form becomes a native form. The app is not “your website in a wrapper” — it pulls structured data and draws the interface itself.

But not everything you want in an app lives inside your WordPress site, and not everything is worth rebuilding as native content. A few examples:

• A third-party booking or scheduling tool that already has its own web page.
• A partner’s storefront, a sponsor’s page, or an external help portal.
• A legal document (terms of service, privacy policy) that you maintain once on the web and don’t want to duplicate.
• A web app you already operate that would be expensive to re-implement natively.

For these, MAM Suite gives you the Web URL content type: a button whose entire job is to open a web address. You configure the address; the app loads it.

What the button actually is, under the hood

In MAM Suite, every kind of app button is backed by a small “content class.” The Web URL button is the local_app_web_url class
(mam-main/includes/content-classes/local-app-web-url-class.php). Compared to most content classes, it’s deliberately thin — no native rendering logic, no post lookup, no layout. Its configuration is essentially one text field, holding a URL.

You can see this in two places in the admin builder:

• When you drop a new Web URL button onto a screen, its blank state is just a text input prompting for an address (the placeholder is http://).
• When you edit an existing one, you’re editing that same URL field.

When the app asks for this button’s configuration, the content class just hands back the URL you saved, more or less as-is — it’s the mobile app that decides how to present it. That division of labor matters for the rest of this article: WordPress stores the address; the app decides how to open it.

The button is registered with an internal type of url, which is the signal the app uses to treat the saved value as a web address rather than, say, a post id or a native action.

Everything else — how the page opens, whether the URL gets personalized before it loads — happens on the app side. WordPress’s job stops at storing the address and handing it over. Keep that boundary in mind through the rest of this article: what follows describes app-side behavior, not WordPress settings.

The key distinction: in-app browser vs. external link

The app can open that URL in one of two ways, and which one it picks is the decision that changes how the button feels to a user — it’s the distinction this article is named for.

In-app browser (the page stays inside the app)

The web page opens in an embedded browser view — a web page drawn inside your app’s frame. The user is still “in your app”: there’s a way back, your app chrome is still around them, and when they finish they return to the screen they came from. This is the right choice for almost everything, because it keeps the experience continuous. A user who taps “Book a class” and is bounced into a booking page should be able to finish and come back without feeling like they left.

External link (the page opens in the phone’s browser)

The app hands the URL to the device’s system browser (Safari on iOS, Chrome or the default browser on Android). The page opens outside your app. The user has effectively left — to get back, they switch apps. This is the right choice in a narrower set of cases: a download that the system browser handles better, a payment or login flow that explicitly needs the real browser, or any link where leaving the app is genuinely the intent.

Here’s the practical rule of thumb for deciding what a given Web URL button should do:

• Should the user come back to the app when they’re done? The in-app browser is what you want.
• Are you intentionally sending them away? The external link is the right fit.

Most Web URL buttons want the in-app browser. The external behavior is the sharper tool — easy to reach for, easy to regret, because every external hop is a moment where the user might not return.

Which mode a given button uses is the app’s call, not something you’ll find as a field in the WordPress builder — the content class only ever stores the address. If you need a specific button to open externally instead of in-app, that’s something to arrange with your app build; it isn’t a per-button WordPress setting today.

Personalizing the URL

A static URL is fine for terms-of-service pages and sponsor links. But many real uses want the URL to know who is looking — a profile page, an account dashboard, an order-status lookup.

Because the WordPress content class stores and hands over the address unchanged, any personalizing happens on the app side, not in the URL field you edit. Two ideas are worth knowing, even at a conceptual level:

• Substitution tokens — a URL written with a placeholder (for example, the signed-in user’s id or the app’s account code) that gets filled in with the current user’s value before the page loads, so one authored URL serves every user their own address.
• Shared authentication — when the in-app browser opens a page on the same domain as your WordPress site, the user’s WordPress login can carry through so the page sees them as already signed in. The same-domain boundary is the catch: a page on a different domain won’t see that login state, so a third-party tool generally still needs its own sign-in.

Whether you have access to either — and exactly how — depends on your app build. Treat them as capabilities to confirm with your build, not fields waiting for you in the WordPress builder.

When to use Web URL — and when not to

Think of a Web URL button as a fallback, not a default. Reach for it when rebuilding the content natively would be wasteful or impossible — and prefer a native WP content type whenever the content genuinely lives in your WordPress site.

Use a Web URL button when:

• The content lives on a third-party site you don’t control.
• It’s a self-contained web tool (booking, ticketing, surveys) you don’t want to rebuild.
• It’s a single canonical document you’d rather maintain once on the web.
• It’s an existing web app where native parity isn’t worth the cost.

Prefer a WordPress content type instead when:

• The content is a page or post on your own WordPress site → use WP Content, which renders the post body natively through the normal the_content pipeline.
• You want a native detail view for a single post → WP Post Content.
• You want a scrollable, native list of posts in a category → WP Post Category.

The difference is not cosmetic. Native content types give you real mobile UI — native scrolling, app theming, featured images, the layout the app draws for you — and they keep working offline-tolerant and fast. A web page inside the app is always a web page: it depends on the network, it carries its own styling, and it won’t automatically match your app’s look. Use it where the web is genuinely the right home for that content, not as a shortcut to avoid authoring native screens.

How this connects to the rest of MAM Suite

• Content classes overview. Web URL is one of MAM Suite’s content classes — the building blocks (Login, Map, Favorites, Phone Call, the WP content types, and more) you assemble screens from in the no-code builder. It’s one of the simplest members of that family, precisely because the app does the rendering, not WordPress.
• WP Content / WP Post Content / WP Post Category. These are the native counterparts to Web URL and the first thing to reach for when the content is yours.
• Punch Out and other action buttons. Some buttons do something rather than show something; Web URL sits between those and the content-rendering buttons — it shows a page, but a page the app didn’t build.

If you remember one thing: a Web URL button trades native fidelity for reach. Use it to bring in what the web does best, and let WordPress content types handle everything that’s truly yours.

Related

• Content classes overview
• Content class: WP Content
• Content class: WP Post Content
• Content class: WP Post Category
• Content class: Punch Out