Connect your own domain
Move a published site from the builder's address to your own domain without breaking email, sign-in or payments.
When to use this
When the site works on the builder's preview or platform address and you are ready for visitors to use your own domain.
Before you start
- A domain you own, such as [YOURDOMAIN.COM], with registration active.
- Login access to the company where the domain is registered or its domain settings are managed.
- A published version of the site that already works on the platform address.
- A platform plan that supports custom domains.
- A choice of primary address: [YOURDOMAIN.COM], [WWW.YOURDOMAIN.COM] or [SUBDOMAIN.YOURDOMAIN.COM].
- A record of any email service already using the domain. Do not remove email settings while connecting the website.
The prompt
Connect this published site to my domain [FULL DOMAIN]. The domain is managed at [DOMAIN PROVIDER]. I want [PRIMARY ADDRESS] to be the main address and [OTHER ADDRESS] to send visitors to it. Do not change the site's design, content or working features. First check whether this platform can connect the domain automatically or needs me to change settings at the domain provider. If an automatic option requires buying, transferring or renewing a domain, changing plans or accepting a charge, stop and show me the choice before doing it. If manual setup is required, show me the exact domain records displayed by this project's domain settings. Domain records are address-book instructions that tell browsers where the site lives. For each required record, tell me the record type, name or host, value or destination, and whether an old conflicting website record must be removed. Do not guess values and do not give generic example values when the project provides exact ones. Preserve all records used for email, verification and other services unless the platform explicitly identifies a conflict and I approve the change. In particular, do not remove mail-delivery records just because they are not needed for the website. Add both [PRIMARY ADDRESS] and [OTHER ADDRESS] when the platform supports them. Set one clear primary address so search engines and shared links do not treat them as different sites. Keep the platform's original address working during setup unless the platform requires otherwise. After I make the required changes at [DOMAIN PROVIDER], verify the domain inside the platform. Wait for the secure padlock to appear before calling it complete. If verification is pending, explain that address changes can take time to spread and tell me when and where to check again instead of repeatedly changing correct records. Once the domain is live, update the site's preferred public address, public page list for search engines and link-sharing information. Recheck sign-in, forms, email links, payments and any outside connection that returns visitors to the site, because those may still contain the old platform address. Test [PRIMARY ADDRESS] and [OTHER ADDRESS] in a private browser window and on a phone. Confirm the correct site opens, the padlock appears, the non-primary address sends visitors to the primary one, and no platform preview address appears in public links. Keep the process cautious and explain each owner action in plain language. Finish with a short checklist showing what is complete, what is still waiting, and which domain or email renewal remains my responsibility.
Already building? Paste this into your project. Starting fresh? Open a free account with a compatible builder below.
Build it on
What this creates
- A custom domain connected to the published site
- Exact owner instructions for any domain-provider changes
- One primary address with the alternate version pointing to it
- A secure browser connection with the padlock
- Updated public links and search-engine address information
- A final check of sign-in, forms, payments, email links and outside connections
Check it worked
Paste the prompt, wait for the build to finish, then confirm these — in plain language, no technical checks needed:
- Typing your own domain opens the correct published site
- The browser shows a padlock and no security warning
- Both the main and alternate domain versions lead to one chosen address
- The site's menu, forms, sign-in and any test payment still work on the new address
- Sharing the new address shows the correct site title, description and image
- Email on the same domain still sends and receives normally
- The platform preview address no longer appears in public buttons, confirmations or share previews
Something missing? That's normal — ask for it in one short follow-up message rather than re-running the whole prompt.
Next steps
Fix the main and www versions
When one version works but the other shows an error or a different site
Review the domain setup for [YOURDOMAIN.COM] and [WWW.YOURDOMAIN.COM]. Set [PREFERRED VERSION] as primary and make the other send visitors to it using the platform's supported method. Preserve all email records and do not change any unrelated subdomain.
You'll know it worked when: Both addresses open the same site and finish on the preferred address with a secure padlock.
Update search tools after the move
Once the custom domain works consistently
Update the site's preferred public address, public page list and search-engine verification for [FULL DOMAIN]. Check that public pages name the custom domain rather than the platform address. Do not block the platform address until the custom domain has been verified.
You'll know it worked when: The site's search information consistently names the custom domain and every public page is listed under it.
Recheck links from emails and payments
If the app sends login, confirmation, invoice or payment-return links
Find every customer email, sign-in link, password-reset link, payment success or cancellation return, and outside connection that still uses [OLD PLATFORM ADDRESS]. Update it to [FULL DOMAIN], then run safe tests for [IMPORTANT FLOWS]. Do not change private keys or payment settings unless a provider requires the new return address.
You'll know it worked when: Test messages and payment returns open the custom domain instead of the old platform address.
Watch out for
- Domain changes are not instant everywhere. Correct settings may work for you before they work for someone elsewhere. Wait up to 72 hours before replacing values that match the platform's instructions.
- Deleting the wrong record can break business email. Website records and email records share the same control panel. Preserve mail and verification records unless you know exactly why one must change.
- A padlock can take longer than the first page load. Do not announce the domain while the browser shows a security warning; wait for the platform to finish the secure certificate.
- Two public versions can split links and search signals. Choose one primary address and send the other to it. More on search after the move: Will Google Find Your AI-Built Website?
- Old return links can break sign-in or payments. Test password resets, confirmations, invoices and payment success or cancellation after the domain changes.
- Owning a domain is an ongoing responsibility. Keep the registration email current and renewal active; connecting it to a site does not make the builder responsible for every registrar renewal.
Platform notes
Base44: Custom domains are available on Starter and higher paid plans. Base44 can connect a domain bought through it or one managed elsewhere, issues the secure certificate automatically, and advises allowing up to 72 hours for outside domain changes to spread. Lovable: Connecting a new custom domain requires a paid plan and the project must be published. Lovable can sell and connect a domain automatically or connect one from another provider; outside domain changes can also take up to 72 hours. v0: v0 publishes through Vercel and gives each deployment a platform address. Add a custom domain from the Publish area or open the connected Vercel project for the exact domain instructions.
Spend fewer credits
Every builder charges you for the work its AI does — so the cheapest habit is thinking before you build. These six rules cut most of the waste, whichever platform you choose.
- Plan in a free chat first. Sketch the whole thing in ChatGPT, Claude or Gemini — pages, features, what each form collects, what it should look like. Thinking there is free; thinking inside a builder is billed.
- Start from a written prompt, not a sentence. "Make me a website" is the most expensive sentence in AI building. A complete first prompt — like the ones on this site — saves dozens of correction rounds.
- Don't be lazy with the details. Every detail you leave out comes back as a correction you pay for. Business name, colors, every page, every form field, what happens after someone submits — put it all in the first prompt.
- One change per message afterwards. "Fix the header, and the form, and the colors" produces a tangle that costs more to unpick than it saved.
- Stuck? Stop patching. If the same fix fails about three times, don't send a fourth correction — describe the whole section's desired end state in one fresh message instead.
- Start free. Upgrade when you need more. Use the free allowance to build and explore your first version. Upgrade when you need more usage or paid features, and check any connected service costs before launch.
The prompts on this page are written to do most of this work for you — that's the point of them.
Read the full guideRelated playbooks
Last reviewed: 2026-10-09