How to set up branded client domains in Readdy

Quick answer

To set up branded client domains in Readdy, choose separate subdomains for platform access and published client sites, add the generated DNS records, verify the connections, and test both destinations from a client account. White Label requires Agency Pro or higher and access to the relevant DNS provider. The platform login supports subdomains rather than a root domain. A site domain uses a branded base subdomain with a wildcard record. Decide whether that site domain should affect future publications or existing published sites before applying the change, because the choice can alter live addresses.

Prerequisite: an eligible Readdy plan, domain DNS access, and a written decision about existing site addresses.

1. List the client login and website addresses you need.
2. Prepare separate platform and site subdomains.
3. Connect and verify the platform domain.
4. Configure the site domain and publication scope.
5. Test client access and published site addresses.
6. Update onboarding instructions and record the configuration.

Before you start

You need Agency Pro or higher, control of the relevant DNS records, and a decision about which published sites should change. Prepare the address choices before editing a live configuration. If you are still choosing how to host client sites, compare the hosting and domain options for freelance projects before configuring the agency addresses.

Use separate labels for the two destinations. The platform address is where clients sign in; the published-site address is where visitors use a client's website. In an illustrative setup, app.example.com could be the platform address and sites.example.com the published-site base. Those are example names, not DNS targets. Copy actual record values from Readdy during configuration.

Find the person who manages the DNS zone. Domain registration and DNS management may be handled in different places, so confirm where the records must be added. Tell that person which subdomains you intend to use and check whether they already serve another purpose.

If sites are already live, list their current addresses and the people who use them. Mark whether each address is a client login or a public website. This list determines the communication needed when you change Platform Domain or apply a new Site Domain to existing publications.

Prepare a test client account and one representative published website. You will use them to check both destinations after verification. Email sending is a separate setup: if branded messages are part of the rollout, prepare the verified Resend account and sending domain as well.

Steps

Complete the platform connection before relying on the new login URL, then configure published-site domains according to the migration scope you selected. Follow the generated records for your account rather than reusing records from another project.

Step 1: Define the address map

Write down the exact client actions each address must support. The platform address is where the business owner signs in to reach the dashboard or editor. A published-site address is where that business's visitors read pages and use the website. Give the two destinations distinct names in your checklist so reviewers know which one they are testing.

Keep a separate column for the current address and intended address when changing an existing setup. Add the person who must receive an updated link. This worksheet is especially useful if a client has saved the login address in internal notes or a bookmark. The result of this step is a change plan, not a DNS change, so unresolved ownership questions can be fixed before anything moves.

Step 2: Prepare the subdomains

Choose an available platform subdomain, such as app.example.com or editor.example.com. Readdy does not support a root domain such as example.com for the platform login. Make that distinction before you give the planned login address to clients or put it into onboarding material.

Select a different base subdomain if you want published client sites under your agency's domain pattern. In the example sites.example.com, Readdy uses the base for a wildcard arrangement. Check existing DNS use with the domain administrator before adding records. The intended result is a pair of addresses that do not accidentally replace an unrelated service already using the same names.

Step 3: Connect the platform domain

In Readdy's White Label domain configuration, enter the platform subdomain and use the generated CNAME value at your DNS provider. Save the record at the provider, then return to Readdy to verify the connection. Refer to the White Label guide for the current configuration flow and preserve the actual record values in the agency's private setup notes.

Verification can remain pending while DNS changes propagate or SSL is issued. Readdy indicates that this process can sometimes take up to 72 hours for white-label domains. If the record is correct and certificate issuance is still in progress, recheck the status rather than repeatedly replacing valid DNS values. Only treat the new login destination as ready after it becomes active and opens successfully.

Changing a live Readdy Platform Domain immediately invalidates the previous login URL. Share the new login address with the team and clients before or at the same time as the switch. Do not assume an old bookmark will continue working because a different domain change elsewhere on the platform uses a redirect.

Step 4: Configure the site domain and scope

Enter the branded base subdomain for published sites, such as sites.example.com. Readdy handles the wildcard pattern from that base; you do not need to type the wildcard prefix into the base-domain field. Add the generated wildcard CNAME record at the DNS provider, then verify the connection in Readdy.

Choose whether the domain applies only to future publishes or to all published sites. Use the future-publication scope when the intention is to preserve current site addresses while adopting a new pattern for later work. If existing sites must change, review each affected client before selecting the broader scope. The agency should know which live addresses it is authorizing the platform to change.

The transition behavior depends on the change. The first connection of a custom Site Domain applied to all published sites redirects previous site URLs to the new address. A later change from one custom Site Domain to another, applied to all published sites, makes the old URLs stop working immediately. Treat these as different transitions when planning client communication and testing.

Step 5: Test the client and visitor journeys

To verify a branded platform domain in Readdy, open the new login address, sign in as a test client, and confirm the intended project is accessible. This checks the customer's actual route rather than relying only on an administrator's view. If a redirect or saved session obscures the result, use a fresh browser session and repeat the journey from the written instructions.

Open a representative published website using its intended address. Check that the correct site loads, navigation stays within the expected website, and important links do not send visitors back to an outdated location. Review the address in the browser as well as the content on the page. A recognizable design alone does not show that the correct domain is serving it.

Step 6: Update instructions and assign an owner

Replace login links in onboarding notes, account-team templates, and internal support material. Tell clients which address is for editing and which is their public site. If both changed during the rollout, communicate them as separate actions. A short, precise explanation is easier to follow than a general message announcing that the agency has upgraded its platform.

Record the final domain choices, application scope, DNS administrator, and support owner in private operational notes. Readdy provides the white-label website builder controls, while the agency still needs an accurate record of the configuration it has chosen. Assign someone to update that record during a rebrand, domain renewal, or future platform-domain change.

How to verify it worked

The setup is complete when the new platform address opens the intended client experience and the affected public websites use the intended domains. A saved DNS record is only an intermediate result.

For platform access, start with the new address in a fresh browser session and sign in as the test client. Confirm the client reaches the assigned project. Then open the written onboarding instructions and check that they use that same address. If Platform Domain changed, replace old login links because the previous login URL is no longer valid.

For the site-domain setting, check a newly published site and any existing sites affected by the selected scope. Write the expected address next to the one that actually opens. When preserving existing sites through the future-publication setting, confirm that those older addresses still behave as intended.

If the domain remains pending, inspect the generated record with the DNS administrator before changing anything. A correct DNS record and a pending certificate can coexist. Readdy allows up to 72 hours in some cases for white-label DNS and SSL, so keep the destination out of customer instructions until it is active.

Finally, check a link from an actual test invitation if invitations are part of the service. A correctly configured domain does not fix an old address copied into an onboarding message. Review the delivered route from the recipient's inbox to the assigned project.

Common pitfalls

The most disruptive mistakes come from mixing login domains with website domains or applying a change to more live sites than intended. Review the scope before saving, especially when existing customers already rely on published links.

Entering a root domain for platform access will not meet Readdy's platform-domain requirement. Repeatedly changing DNS while SSL is pending can also obscure a configuration that was already correct. Follow the generated record, confirm it with the DNS administrator, and allow the stated verification process to complete before drawing conclusions from a temporary pending status.

Do not generalize the first custom-site-domain redirect behavior to every later change. The old address can stop working when moving between custom Site Domains. Preserve the current URL inventory and update customer-facing links deliberately. If the immediate goal is branded client access, the Site Domain is optional, so an agency can configure branding and platform access before changing published-site addresses.

Conclusion

For agencies configuring branded client access, Readdy White Label supports separate platform and site domain settings, generated DNS records, and explicit verification. Agency Pro or higher, DNS access, and a deliberate application scope are essential prerequisites. Keep an address inventory and client communication plan alongside the configuration so the rollout remains manageable.