Restaurant Custom Domain Guide for Online Ordering

Last verified: 2026-08-28

A platform subdomain is fast for launch; a custom domain becomes a durable brand asset. Guests can remember it, and every campaign points to an address you control.

Choose a clear domain

Prefer a short restaurant name without confusing spelling or extra hyphens. Keep registration under the business owner's account.

Connect DNS and SSL

Your storefront provider will give DNS records. Add them at the registrar, wait for verification and confirm HTTPS before promoting the link.

• Verify desktop and mobile
• Test checkout and payment return
• Keep the old subdomain redirecting

Launch without broken links

Update Google Business Profile, Facebook, Instagram, QR codes and printed materials. Monitor orders and analytics during the first day.

What a custom restaurant domain should accomplish

A custom domain gives the restaurant a stable address it controls for discovery, menus, ordering and support. It does not by itself improve rankings or security. The value comes from consistent ownership, correct DNS, encrypted delivery, one canonical host, reliable redirects and an ordering experience that preserves the restaurant's identity.

Decide the domain's role before configuration. It may be the primary website, a dedicated ordering subdomain such as order.example.com, or a redirect to an existing hosted storefront. Write the intended public URL, owner and fallback path. Avoid launching several equivalent hosts that expose the same content without canonical and redirect rules.

Choose and register the domain safely

Do not let an agency or departing employee become the only legal or technical controller. A missed renewal or inaccessible registrar account can interrupt orders and email. Keep a small domain register containing registrar, nameservers, purpose, renewal mode, verified owner and recovery procedure without storing passwords in the document.

• Use a name customers can type and recognize
• Prefer a trusted registrar with account recovery controls
• Register the domain in the business-controlled account
• Enable multi-factor authentication where available
• Record renewal owner, billing contact and expiry date
• Keep registrant and DNS access separate from a single contractor
• Use least-privilege access for technical helpers
• Store recovery codes through the business's approved process

Understand the DNS records involved

Use the exact host and value supplied by the platform. The root domain, www and an ordering subdomain are different names. Before editing, export or record the current zone and identify email and verification records that must remain. DNS changes can be cached; confirm resolution from more than one resolver before declaring the setup complete.

Recommended host and redirect pattern

Choose one canonical public URL—for example, https://example.com/ or https://www.example.com/—and permanently redirect the alternate host to it. If the main site already exists, an ordering subdomain can isolate the hosted storefront while the primary site links to it. The exact pattern depends on platform capability and existing search equity.

Redirect HTTP to HTTPS and avoid chains such as HTTP root to HTTPS root to HTTPS www to another path. Preserve useful paths when migrating where there is a clear equivalent. A redirect to the homepage for every missing menu or content URL can create a poor user experience and soft-404 signals.

TLS certificate and HTTPS verification

The certificate must cover every public host, renew automatically through a tested process and serve a complete valid chain. Wait for DNS verification before expecting issuance. Test both the canonical and redirecting hosts on a normal browser and command-line client; check that no image, script or API call loads over insecure HTTP.

Do not claim a domain is secure merely because a lock icon appears. Authentication, access control, application updates and payment handling remain separate responsibilities. Use HTTPS everywhere, protect registrar and DNS accounts and document the incident route for a misissued, expired or misdirected host.

Connect the domain to a multi-tenant storefront

A SaaS platform must map the requested host to the correct restaurant tenant on the server. DNS only routes traffic; it does not prove which tenant should answer. Verify domain ownership before activation, normalize the hostname, reject unknown hosts and prevent a user from claiming a domain already attached to another account.

Test tenant isolation using known and unknown domains, both with and without www, and direct-IP or altered Host requests where applicable. The response, analytics, asset paths and ordering API must remain associated with the intended restaurant. Custom-domain deletion should remove the mapping and certificate safely without affecting the branded platform subdomain.

Search, analytics and link migration

A host change should be treated as a migration. Capture the old URL inventory, map equivalents and keep redirects long enough for users and crawlers. Do not block the old host before redirects can be discovered. Compare orders and traffic by source before and after, but account for tracking changes before attributing a difference to the domain itself.

• Emit a self-referencing canonical on the chosen host
• Redirect alternate hosts and old equivalent URLs
• Update sitemap URLs to the canonical origin
• Keep crawlable internal links on the canonical host
• Verify the property in the relevant search tools
• Update analytics configuration and referral exclusions carefully
• Replace ordering links in map, social and delivery profiles
• Monitor 404s, redirect chains and indexed host variants

Email and payment dependencies

Website DNS work must not accidentally remove MX, SPF, DKIM or DMARC records used by domain email. Record them before changing nameservers or importing a zone. Test order and support email after the change. If a payment or authentication provider uses allow-listed redirect URLs, add and verify the new HTTPS URLs before switching live links.

Never publish secret keys in DNS, browser code, screenshots or setup guides. TXT verification tokens should be scoped to their purpose, and obsolete records should be removed through a reviewed change rather than a broad cleanup that may break another service.

Launch and rollback checklist

Use a low-risk launch window with a responsible person available. Roll back when orders, tenant mapping, certificates or payment callbacks fail; do not wait for DNS changes while leaving a broken URL in advertisements. Record the actual completion time and follow-up checks.

Ongoing domain maintenance

Review registration, renewal, contact, DNS, TLS and access at a defined interval and whenever staff or providers change. Monitor certificate and domain expiry with more than one responsible contact. Re-test the full ordering path after DNS, CDN, checkout or tenant-routing changes.

Keep the platform-provided subdomain as a documented recovery route when supported, but avoid presenting it as a duplicate public canonical. The restaurant should know which team owns registrar, DNS, SaaS mapping, content and customer support; unclear ownership is the most common reason a simple domain issue becomes a long outage.

A custom domain is useful when operations behind it are reliable. Test the full order journey before replacing public links.

Related guides

• Branded Online Ordering Storefront
• Restaurant Branding System
• Online Food Ordering in Bangladesh
• Compare restaurant management software

See this workflow in Rosuii: Use your own restaurant domain

Start using Rosuii for free