How to connect a custom domain to Lovable

Connect the address to the right project

A custom domain connection involves your domain registration, DNS configuration, and the published project. Identify which account controls each piece before making changes. The registrar and DNS provider may be different services. A domain can also support email, so website setup should not erase unrelated records.

Lovable’s current documentation places custom domains on paid plans and provides domain setup through project settings and publishing controls. Use the current interface and records for your project. The guidance below explains the decisions and checks around that process, not a universal set of DNS values. Official domain reference.

Choose root, www, or a subdomain deliberately

Decide whether the primary site will use example.com, www.example.com, or a subdomain such as app.example.com. A subdomain can host an application separately from an existing public site. Changing the root may replace the destination used by existing customers, so confirm the intended scope.

Use one primary hostname consistently in canonical URLs, the sitemap, internal links, and social metadata. Configure alternate hostnames to behave intentionally, usually by redirecting to the primary address. The hostname choice does not itself guarantee search visibility; consistency and working routes are the practical goals.

Record the existing DNS configuration

Save the current records and identify mail-routing, email-authentication, and verification entries. Change only the records required for the website. If a colleague or provider manages DNS, give them the exact requested record fields rather than asking them to replace the entire configuration.

The table is explanatory. It intentionally contains no reusable IP address or verification token. A value copied from another project or an old tutorial may be wrong for your deployment.

Add the domain through the project workflow

In the current Lovable interface, locate the project’s domain settings or domain option in the publishing flow. Choose the appropriate route for an existing domain or a new registration. Review any purchase separately; connecting a domain you already own should not be confused with buying another one.

Follow the displayed verification instructions. Check how the DNS provider represents hostnames: some ask for only the label, while others show the full name. Verify the resulting record before saving. Do not create duplicated names such as www.example.com.example.com accidentally.

Wait for verification without repeatedly changing correct values

After saving the required records, inspect the platform’s domain status. DNS caching and certificate issuance can take time. If the values are correct, repeated edits may make diagnosis harder. If verification fails, compare the current public records with the project’s requested values and check for conflicts.

Do not bypass certificate warnings and declare the setup complete. HTTPS should work normally on the intended address. If status remains unresolved, collect the hostname, public record values, and platform status for support. Keep account passwords and secret service credentials out of a routine support message.

Test the live address as a visitor

Open the primary hostname, the alternate hostname, a real internal page, and a nonexistent route. Check that redirects preserve useful paths. Test on a device outside the editor session if practical. A working homepage is only one part of domain verification.

Then test forms and login flows. Services may still contain preview-domain callbacks or links. Update those through their supported configuration and repeat the journey. A domain can serve the site correctly while an external integration still points elsewhere.

Diagnose common failures by layer

Avoid treating every symptom as a DNS problem. Once the correct site loads, a broken internal route is likely an application or hosting configuration issue. Isolating the layer reduces unnecessary changes.

Finish search and measurement setup

Update metadata and the sitemap to the primary hostname. Verify site ownership in Search Console through a supported method and submit the published sitemap. Inspect representative public pages rather than assuming every generated route is discoverable.

Check analytics on the production journey and distinguish testing from real acquisition data where possible. If the domain replaces an older site, preserve valuable URLs or create appropriate redirects. A move that breaks established links can undo the benefit of a polished new design.

Document ownership and renewal

Record who owns the domain, who can edit DNS, when registration renews, and which services depend on it. Keep ownership with the business. If a freelancer helps, ensure the organisation retains access after the engagement ends.

A completed connection means the address, certificate, routes, integrations, and maintenance responsibilities are all understood. Recheck those areas after changing hosts, moving DNS, or changing the project’s publishing configuration.