Working sheet
Eleven Places the Vendor's Name Survives a Rebrand
A rebranded dashboard changes the login screen. It does not change the page source, the DNS records, the form confirmation email or the support widget. Where to look before you promise a client otherwise.
A platform rebrand changes what the client sees when they log in. It does not make the platform invisible, and the gap between those two things is where uncomfortable conversations live.
This is a checklist of the surfaces where a vendor's name tends to survive. It is not an argument against white label — the good implementations cover most of this list. It is an argument for checking which ones your tier actually covers before you describe the arrangement to a client in terms you cannot fully honour.
Work down it with the specific plan you are buying, not with the marketing page.
The surfaces a rebrand usually does cover
Start with the good news, because a competent white-label tier handles these and it is worth knowing what you are getting.
The login screen. On platforms that offer rebranding at all, the client logs in at your domain rather than the vendor's. Duda's rebranding covers a branded login screen; 10Web's page describes a dashboard hosted on your domain with your logo, colours and name.
The dashboard chrome. Logo, palette, product name. This is the visible half of the promise and it is the half everyone tests.
System and lifecycle emails, sometimes. This is where implementations diverge sharply. 10Web's page states that all lifecycle, system and payment emails are sent from your domain with your branding. Duda's client-billing emails go out under your email domain with your branding. Neither claim is universal across the category, and on most platforms the answer is no.
The surfaces that leak anyway
Eleven places the platform shows through
The rebrand covers the login and the dashboard. The numbered tiles match the list below.
Now the list to actually check.
1. The page source. Every builder leaves fingerprints in the generated HTML — class-name conventions, asset paths, script hosts, meta generator tags. Anyone who opens developer tools finds the platform in under a minute. No rebranding tier changes this, and none claims to.
2. The asset and script hostnames. Images, fonts and scripts are frequently served from the vendor's CDN. A rebranded dashboard on your domain does not move the CDN, and the hostnames sit in the page source and in the browser's network panel.
3. DNS records. Whatever the client is asked to point at, the target usually names the platform. Anyone with access to the registrar sees it, and the person most likely to have registrar access is the client's IT contact — the one person in the room who will notice.
4. Form confirmation and notification emails. The receipt a visitor gets after submitting a contact form is generated by the platform, and unless the tier explicitly covers transactional email, it carries platform wording or a platform sending domain. This is the most common leak in practice because it happens on live client sites to the client's own customers.
5. The email sending domain and headers. Even where the visible branding is yours, the technical headers often are not. A client's mail administrator reading a full message header sees the sending infrastructure. This is a quiet leak that almost nobody checks.
6. The support widget. If the client can reach help from inside the product, ask where it goes. A rebranded dashboard with a help button that opens the vendor's knowledge base has announced the platform more clearly than a logo would have.
7. The help centre and documentation. Related but separate. The moment a client searches for how to do something and lands on the vendor's documentation, the arrangement is public. Almost no tier covers this, including generous ones.
8. Payment descriptors. If a client pays for anything through the platform, the line on their card statement comes from somewhere. Duda's client-billing page states invoices show your brand and Stripe, which is unusually clear about this; most platforms do not address it at all.
9. App and integration marketplaces. Any third-party app installed on the site sits in an ecosystem with the platform's name on it, and the app's own documentation will name the platform even if the dashboard does not.
10. Publicly available site fingerprinting. Several services publish what a domain is built on, sourced from the page source and DNS. A curious client, a prospective competitor or a next agency can find out in seconds.
11. Your own proposal, six months earlier. The most common leak of all is not technical. It is a written quote, a scope document or an email that names the platform, filed by someone at the client who will read it again during a renewal conversation.
What to do with the list
Three things, none of which involve being less honest.
Check the four that matter to your client specifically. For a professional-services client, the leaks that matter are the login screen and the emails. For a client with an IT department, DNS and mail headers matter more. For an ecommerce client, the payment descriptor matters most. Work out which surfaces your particular client will touch.
Describe the arrangement accurately in writing. "We manage your website on a platform we've rebranded" is honest, checkable and entirely sufficient. "We built you a custom platform" is not, and it will not survive a developer tools panel. The difference costs nothing to get right and costs a great deal to get wrong.
Price the tier against what it actually covers. If the surfaces your client touches are covered at a lower tier, buy the lower tier. Duda's Client Billing, for instance, delivers branded payment emails and checkout from the Team plan at $29 a month annually, two tiers below the plan that rebrands the platform. If the money surfaces are the ones your client sees, that may be the whole of what you need. The tier-by-tier detail is on the Duda agency sheet.
A five-minute audit on a live site
Run this against a site you already manage before you promise anything about a new one. None of it needs a tool you do not have.
- Open the published site and view the page source. Search it for the platform's name, then for the platform's CDN hostname. Note how many hits there are.
- Submit the contact form with your own address. Read the confirmation email that comes back, and then open its full headers and read the sending domain.
- Look up the domain's DNS records and read the target of whatever record points at the platform.
- Log in as the client would. Click the help control, if there is one, and see where it lands you.
- If the site takes payments, make a small one and read the descriptor on the statement.
Five minutes, five answers, and you now know precisely which sentences you can say to a client and which you cannot. Repeat it after any platform migration, because the answers change.
The thing nobody says about leaks
A client who discovers the underlying platform is almost never upset about the platform. They are upset about having been told something that turned out to be shaped differently from the truth.
Agencies build websites on website builders. Clients know this. Nearly all of them are entirely happy about it, because what they are buying is judgement, design and someone to call — none of which the platform supplies. The only version of this that goes badly is the one where the agency implied otherwise and the page source disagreed.
White label is worth paying for when the dashboard is part of what you sell. It is not worth paying for as a way of avoiding a conversation you could have had in one sentence. Which platforms sell the real version, and at what tier, is set out on the best website builder for agencies rack, and what the phrase covers at each one is on what white label actually covers.
Files under
Every sheet in this deck feeds one decision: the best website builder for agencies. Start there for the ranking, then come back for the clause you are arguing about.