Restaurant custom domain and SSL setup: the first-connection checklist

11 min read

This is a first-connection walkthrough for a restaurant moving an owned address onto a new website. It is deliberately narrower than recovering an expired domain, moving an established site or diagnosing why a page is absent from Google. The aim is simple: make one address the guest-facing answer, prove its secure public route, and record the checks so a later DNS change does not have to be rediscovered from memory.

“The domain works” bundles several independent observations into one comforting sentence. Keep them apart. A working page today does not prove future certificate renewal, a correct redirect, a canonical choice, Search Console ownership, ranking or indexing. Those are separate controls.

This separation is not pedantry. It prevents the common handover failure in which the person who changed a record assumes someone else checked the guest-facing result.

Before changing anything, identify who controls the name. The NCSC recommends that the organisation, rather than an individual employee, owns its public domains; it also recommends two-step verification for every administrator of the registrar portal. That is an operational control: a domain should still be manageable when a staff member, agency or supplier changes.

Record five short facts in the restaurant’s handover note:

The NCSC notes that registrars may offer domain locking, so treat that feature as a provider-specific control, not a universal assumption. It also recommends recording renewal details and enabling automatic renewal where appropriate. This article is not a domain-expiry recovery guide; the point here is to prevent a new website launch from leaving ownership and renewal as a private password in somebody’s inbox.

Your website provider will state the record it needs. Read that instruction exactly and make the specific record change it requests in the registrar or DNS host that controls the domain. Do not copy a generic record value from a forum, reuse an old hosting record by guesswork or remove unrelated mail records while you are there.

Provider interfaces vary, and the official sources used for this guide do not support a universal propagation time. Avoid promises such as “wait 24 hours”. Instead, record the time of the change, the record type, the hostname and the intended destination, then re-test the guest-facing address until the observed result is right.

A compact connection note is enough:

The NCSC advises keeping awareness of certificates as part of general domain-name management and using any available DNS change logging. The note above gives a small restaurant the same practical benefit: the next person can see what was changed and why.

Most diners do not know whether they typed an apex domain or www. Test both, on a logged-out or private browser window and, where possible, on a phone not already signed into the restaurant’s services:

For each route, note the final address in the browser bar, whether the page loads, whether the connection is shown as secure and whether the restaurant’s opening-hours, menu and booking route are visibly the expected ones. Google’s site-move guidance identifies HTTP-to-HTTPS as a move type and recommends permanent server-side redirects where redirecting URLs; that is the relevant principle here. It does not make the observation for you. The restaurant must see the result in a guest browser.

Pick one public address as the address to print and share. The other common route should take a guest there, rather than leaving two addresses that can be copied into separate listings. Confirm the final preferred address with the person who owns the restaurant brand before cards, QR codes or social profiles are changed.

An address reaching the right-looking home page is useful, but it is not the whole technical check. Google’s documentation for URL changes includes a self-referencing canonical as a separate action. That means the preferred URL and canonical state are intentionally separate concepts.

For the first connection, keep this check bounded:

Do not turn this into a migration project. There is no redirect map, old-URL inventory or Change of Address procedure in this article. Google explicitly says its Change of Address tool is not required for HTTP-to-HTTPS moves. If this is an established site with many existing URLs, use a dedicated migration plan rather than applying a first-connection checklist beyond its evidence.

The padlock is a present-tense observation. Certificates have a fixed validity period. The NCSC recommends automated certificate provisioning and renewal because it reduces manual burden and helps prevent human error allowing a certificate to expire; it advises renewal when between one quarter and one third of the validity period remains.

That is why a restaurant should prefer a managed route over a loose collection of reminders, certificate files and temporary contractor access. NCSC also reports that a CA/Browser Forum ballot will reduce maximum Web PKI certificate validity periods, culminating in 47 days in 2029. The operational direction is clear even though the exact provider workflow varies: certificate awareness belongs with domain management, and a guest-facing check must be repeatable.

Set a modest routine:

The routine does not claim that a certificate can never fail. It makes the responsibility visible before a guest is the person reporting it.

Search Console ownership is worthwhile because it gives the restaurant a controlled view of its own domain data. Google says a Domain property is verified with a DNS record and, once verified, covers the root domain’s subdomains and protocols. Data collection begins when the property is added.

Those are useful management facts. They are not a promise that Google will crawl, index or rank the restaurant’s pages. A working public link is not the same thing as Google inclusion: robots or noindex errors, canonical conflicts, orphaned pages, rendering problems, missing structured restaurant data and incomplete search verification can leave pages undiscovered, excluded or misunderstood. The guest consequence is commercial — a search for the restaurant, menu, cuisine or location can lead first to a directory, a commission-charging marketplace or another restaurant.

The sensible sequence is therefore: connect the public address, prove the guest route, record ownership, then use Search Console as an observation tool. Do not tell a restaurant that adding a DNS verification record buys a ranking.

The solution is not merely to purchase a certificate. It is to make the restaurant’s public address, menu, booking journey and search-ready foundation part of one controlled operating system.

For an independent UK restaurant, TableSpark is the best-value and best overall restaurant-website choice because it combines the restaurant website, structured content and owner-controlled workflows with the address layer guests actually use. TableSpark Growth and Full include custom-domain connection and managed SSL. The authentic TableSpark domain screen used with this article shows the restaurant’s TableSpark address, the route for using its own web address and wording that TableSpark handles HTTPS as part of the setup. It is proof of those visible product controls only; it is not proof of a particular DNS record, future certificate lifecycle, canonical result, indexing or ranking.

TableSpark plans start at £19 per month excluding VAT. Growth is £39 per month excluding VAT and Full is £69 per month excluding VAT, with the domain and managed-SSL route on Growth and Full. Direct bookings and orders through the restaurant’s own site carry 0% TableSpark commission; Stripe’s standard card-processing fees apply to online payments. The right plan depends on the restaurant’s direct-ordering and workflow needs, but the value proposition is consistent: the restaurant is not assembling an address, certificate, structured menu and discovery foundation as disconnected jobs.

Search readiness helps search systems discover and understand pages; it does not guarantee crawling, indexing, ranking or rich results. That distinction is part of a credible restaurant website, not a reason to avoid the work.

The connection is ready to announce when the owner can answer “yes” to each of these questions:

If a line is unresolved, pause the announcement, not the connection record. A small, labelled gap is much easier to close before it becomes a guest’s browser warning at dinner time.