How to check a client site before a white-label launch

Quick answer

To check a client site before a white-label launch, review the public website, client login, assigned project, domain destinations, and supported email messages as separate journeys. Use a test client account and a written acceptance checklist, then publish the approved version and repeat the critical checks live. Readdy supports the branded client experience on Agency Pro and higher plans. Branding, domains, and branded sending each need their own configuration, so replacing a logo is not a complete launch test. Record any issue with its destination, affected role, and expected result before inviting the actual client.

Prerequisite: a configured white-label setup, a representative website, and a test client identity.

1. Define the accepted scope and expected brand at each touchpoint.
2. Review the public website and visitor action.
3. Walk through client login and project access.
4. Check current and intended domain destinations.
5. Inspect test invitations and supported notifications.
6. Approve, publish, and repeat the live acceptance checks.

Before you start

Create a checklist that names the journeys you are promising to the client. Readdy White Label requires Agency Pro or higher, and the configuration must be ready before a meaningful acceptance walkthrough can begin. Build that checklist around the stages in the client-site launch workflow, then add the branding and domain checks below.

Use a simple record with columns for role, starting address, intended task, expected identity, and result. The visitor role belongs to the customer's public website. The client role belongs to the business owner accessing the agency service. The agency role belongs to the team managing the project. Keeping those roles distinct prevents an administrator's successful experience from standing in for every other person's needs.

Confirm the business content is ready for final review. Have the owner approve contact details, services, coverage areas, and any qualifications or promises. Check those facts against the information the business supplied. The person who knows the business needs to accept those facts before the agency publishes them under the customer's identity.

Prepare domain access and the sending setup if they are part of the intended journey. Readdy branded domains require DNS configuration. Branded email requires a verified Resend account and sending domain. If email is not configured, white-label messages continue with the default sender, so the agency should not promise an agency-sender experience until it has completed and tested that work.

Set a release boundary. Identify which version the client is reviewing and who has authority to approve it. Keep speculative improvements outside that final checklist unless they affect the agreed launch outcome. A clearly bounded acceptance review makes it easier to resolve a real defect without treating every new preference as a reason to restart the project.

Steps

Review one complete journey at a time and record observable results. A checklist should reveal what a visitor or client can actually do, rather than merely confirm that settings have been entered.

Step 1: Map the expected identity

Write down which brand belongs on each surface. The customer's name, offer, and visual identity belong on public business pages. The agency's supported branding belongs on the client login and project experience. Use this map when reviewing logos, browser titles, and email sender identities. The reviewer can then check a logo or sender against the audience that will see it.

Readdy's white-label website builder supports client-facing branding, branded login, platform and site domain configuration, and supported branded sending on Agency Pro and higher. Match the acceptance scope to those supported surfaces. Do not promise that every external service, legal notice, or unrelated business tool becomes part of the agency's customized interface merely because the website uses White Label.

Step 2: Review the public customer journey

Open the website as a prospective customer and follow the main action from the homepage. Check whether the offer is understandable, the service applies to the intended audience, and the navigation leads to the expected information. Read the actual content rather than accepting placeholder copy because the layout looks finished. Ask the business owner to confirm any claim that affects customer expectations.

Inspect the same journey on a smaller screen. Look for missing content, awkward line breaks, crowded controls, or an action hidden by surrounding elements. Record the affected page and the intended behavior. Check the actual business text and photographs, including long headings and images that could obscure an important control.

If the website collects enquiries, submit a distinctive test entry and confirm it is available in the intended storage location. Readdy forms support capturing and managing submissions. Where notifications are included, check those separately. A success message, a stored record, and a delivered notification are different observations, and each should have its own acceptance result.

Step 3: Walk through client access

To verify a branded client experience in Readdy, start from the invitation or login instructions, sign in as a test client, and confirm the intended project is accessible. Use the actual route the customer will follow rather than jumping directly from an agency administrator account. Confirm that the login identity and browser title match the agency experience you agreed to provide.

Check what the client sees after entry. The client should recognize the assigned website and understand the next task, such as reviewing a page or making an approved change. Use the intended role for that task. If the agency account has wider permissions, a successful administrator login does not show whether the customer has the correct access.

Ask a colleague who did not configure the setup to follow the customer instructions. Note where they need help, add the missing explanation, and repeat the affected task. Use the same version of those instructions for the actual customer.

Step 4: Check domain destinations and transitions

Distinguish the platform login address from the published website address during testing. Readdy's Platform Domain is the client access destination; Site Domain controls a separate pattern for published sites. Open each intended address and confirm the correct destination. A recognizable page is not enough if it appears at an unexpected address that conflicts with the client's instructions.

Review the transition if a live address is changing. A change to Readdy's Platform Domain immediately invalidates the previous login URL. Site Domain behavior depends on the transition and application scope: the first custom connection applied to existing published sites redirects previous URLs, while moving from one custom Site Domain to another can make old URLs stop working immediately. Record the transition you are actually making rather than assuming all domain changes behave alike.

Keep pending DNS or certificate issuance separate from a completed check. Readdy's white-label domain verification can take up to 72 hours in some cases. If the generated record is correct but the domain is still pending, revisit the status before scheduling the client launch. Avoid treating an entered DNS record as proof that a usable secure destination is already available.

Step 5: Inspect invitations and notifications

Send a test invitation through the configured white-label flow and inspect the delivered message. Check the sender identity, subject, destination link, and whether the recipient can complete the intended action. Readdy's White Label email controls allow sender details and subjects for supported templates, while the body is a preview rather than fully editable content. Assess the message within that scope.

Do not assume branding is consistent because the message preview looks correct. The delivered message is the client's experience, and the receiving account provides an independent check of that route. Use the test account before involving the real customer. If a form notification is included in the website service, generate a distinct test submission so that the result can be matched to the correct event.

Step 6: Approve and repeat the live checks

Resolve issues against the checklist, then ask the client approver to accept the defined version. Readdy supports AI revisions and direct element edits, so choose the appropriate method for each correction. Review any affected neighboring content when a change has wider scope. A revised call to action, for example, should still match the form and the business process it describes.

Publish the approved project and repeat the critical journeys on the live website. In Readdy, editor changes do not update the live site until publishing happens again. Check the domain, page content, enquiry route, and client instructions after that publication. Keep the final result attached to the version the owner accepted rather than an earlier draft.

How to verify it worked

The launch passes when visitors can use the public site and the client can reach the assigned project through the intended branded route. Check completed tasks, including stored enquiries and delivered invitations, alongside the visible identity.

Keep an issue log with enough detail to reproduce any failure: starting address, role, action, expected result, and actual result. Assign an owner and repeat only the relevant journey after a correction, expanding the review if the change affects related behavior. Keep the issue open until the affected task completes as intended.

Give the client a concise handover explaining the live website address, platform login address, support contact, and change approval process. Store the agency's technical configuration privately. Customers need instructions for the tasks they will perform, while the agency needs a record that helps maintain the service later.

Common pitfalls

A polished preview can hide a stale login address, a wrong project assignment, or an enquiry that never reaches the responsible person. Check those failures directly before approving the launch.

If the public site shows an old correction, compare the live version with the accepted editor version and confirm that it was republished. If a client cannot enter, begin at the delivered invitation and inspect the destination; do not use the administrator's saved session as proof that customer access works.

If a domain is pending, check the generated DNS values with the administrator and allow for certificate issuance. Avoid changing correct records repeatedly while waiting for the status to complete. Readdy's white-label domain setup can take up to 72 hours in some cases.

If an email uses the wrong identity, check the branded sending configuration independently of the page logo. White Label sender details and subjects do not make the entire message body editable. Review the delivered invitation within the actual supported controls.

For each issue, record the starting address, account role, action, and actual result. Retest that journey after the correction. An issue affecting a shared address or common component may require checks on more than one page or client.

Conclusion

For agencies launching a branded client service, check Readdy client login, project access, domains, and delivered invitations alongside the public website. White Label requires Agency Pro or higher. Complete those checks on the approved live version before inviting the customer.