Cloudflare DNS Records for Small Websites

Practical verification workflow for this page

Before changing a setting, write down the current hostname, record type, value, proxy state, SSL mode, redirect owner, and expected visitor URL. This small worksheet keeps the diagnosis factual. A DNS record problem, an HTTPS certificate problem, a redirect problem, and a cache problem can look similar in a browser, but they are solved in different layers.

Example workflow: first query the exact hostname, then open the same hostname with HTTPS, then check whether the final URL is the preferred root or www version, then load one static asset. If the asset updates but the page does not, focus on HTML delivery. If DNS resolves but HTTPS fails, focus on certificate and SSL mode. If both hostnames bounce, focus on redirect ownership.

• Record the before value and the expected after value before editing any DNS or HTTPS setting.
• Test root and www separately because they may have separate records, certificates, and redirects.
• Keep mail, verification, and non-web service records separate from ordinary web records.
• Use the related guides on this site to move from records to SSL, proxy state, redirects, cache, and final launch checks.

This page is designed for small websites where one person may manage registrar, host, and Cloudflare settings. Clear notes matter because later troubleshooting often begins weeks after the original change, when the reason for a record or redirect is no longer obvious.

Keep a small comparison table in your own notes with three columns: intended setting, current setting, and test result. The intended setting explains the plan, the current setting records what is actually configured, and the test result shows what a visitor or resolver sees. That table makes it easier to notice when a web record is correct but a redirect is wrong, or when a certificate is valid but the wrong hostname is canonical.

If the page concerns a failure, preserve the exact symptom before editing. Browser messages, final URLs, certificate names, returned IP addresses, and response status codes are clues. Changing several unrelated controls at once can hide the original clue and make the next test less useful.

Small-site operating example

Imagine a brochure website with two public hostnames: example.com and www.example.com. The intended visitor path is simple: both names should resolve, both should load with HTTPS, and one should redirect to the preferred canonical hostname. A practical Cloudflare worksheet for that site starts with the registrar nameserver check, then the zone record check, then the proxy-state check, then the SSL-mode check, then the redirect check. If the apex record points to the old host while www points to the new host, the browser may appear inconsistent even though both records are technically valid. If the origin certificate covers www but not the apex, Full strict can fail only on one hostname. If a page rule, host panel redirect, and application redirect all exist at the same time, the final URL may loop even though DNS is correct.

For a static host, the example values may be a CNAME for www to the host target and an apex flattening record or provider-specific record for the root domain. For a VPS, the values may be A and AAAA records to the server address. For a site that also uses email, MX, SPF, DKIM, and DMARC records should be checked as a separate mail group. A good rule of thumb is to change only the web hostnames when launching the website and leave mail hostnames alone unless the mail provider specifically gives new values.

Troubleshooting table for this route

Deep troubleshooting sequence

Run the same four tests in the same order whenever the symptom is confusing. First, confirm the authoritative nameservers at the registrar and make sure they match the nameservers assigned to the active Cloudflare zone. Second, confirm the record answer for the exact hostname. Third, test HTTPS and certificate coverage. Fourth, test redirects and cache with a fresh URL. This sequence prevents the common mistake of changing cache rules when the actual problem is an old registrar nameserver, or changing DNS when the actual problem is a redirect rule.

For a small brochure site, write the expected result in plain language: root domain answers from Cloudflare, www reaches the same site, HTTPS is valid, one hostname is canonical, old HTTP requests end on HTTPS, and email records still point to the mail provider. If any one sentence cannot be verified, keep the next action limited to that layer. The most reliable site owners of small sites are not the people who change the most settings; they are the people who can explain which setting owns which symptom.

When a host gives a target value, copy it exactly and note whether it expects a CNAME, A record, TXT record, or nameserver change. Provider dashboards sometimes use labels such as host, name, alias, target, points to, destination, and value in inconsistent ways. For Cloudflare DNS, the record name identifies the hostname being answered and the content value identifies the target. Mixing those two fields is a common source of failed verification.

After a fix appears to work, perform a final visitor check from a clean browser session. Open the canonical URL, the alternate hostname, and one important internal page. Confirm that the page loads over HTTPS, the address bar ends on the expected hostname, and static files are not stale. Then save the final record list, SSL mode, redirect owner, and cache notes for the next person who has to maintain the site.

Validation notes before calling the page complete

Give the change a final review with a written pass or fail for each layer. Nameservers should point to the active zone. Web host records should answer for the expected hostnames. HTTPS should use a certificate that covers the exact hostname. Redirects should have one clear owner. Cache should be checked only after the fresh origin response is known. This final review is valuable because it turns a stressful launch into a set of small observations rather than one vague complaint that the site is down.

If a test fails, write the failed layer beside the symptom. For example, if the authoritative DNS answer is wrong, the next action belongs in DNS. If DNS is correct but the certificate name is wrong, the next action belongs in certificate or SSL mode. If HTTPS is valid but the address keeps changing between root and www, the next action belongs in redirects. If the fresh page is correct but visitors see stale content, the next action belongs in cache. That discipline saves time and reduces risky changes.

Also keep screenshots or copied response notes for the final state: record values, proxy state, SSL mode, redirect target, and one successful page load. These notes are useful during renewals, host migrations, provider outages, and future redesigns because they explain why each setting exists. A small site does not need a complicated runbook, but it benefits from a simple, public-facing maintenance note that separates DNS, HTTPS, redirect, and cache responsibilities.

For routes about cache or updates, use neutral publishing language: confirm the current page, confirm the expected page, then decide whether the stale response comes from browser cache, Cloudflare cache, host cache, or the application. Do not purge everything as the first step if the origin is still serving old content. Do not edit DNS when the real difference is an HTML cache rule. The safest fix is the narrowest fix that matches the evidence.

Route-level checklist

Use the checklist as a calm page-by-page routine. Example: if a visitor reports that the root domain works but the www hostname fails, do not immediately change every record. Write down the two hostnames, compare the authoritative answers, compare HTTPS behavior, then compare the final redirected URL. If only one hostname fails, the likely cause is a split record, certificate coverage difference, or redirect rule that handles one name but not the other. If both hostnames resolve to the expected place but the browser still loops, the likely cause is usually SSL mode or duplicate redirect ownership rather than the DNS record itself.

Another example: a static website appears unchanged after a launch. The DNS record may be correct while the browser, edge cache, or host build cache is still serving an older file. Test the HTML document and a CSS or JavaScript asset separately. If the asset filename changed but the page still looks old, inspect browser cache and edge cache. If the asset filename did not change, inspect the host build output. This route-level habit keeps each troubleshooting step attached to evidence that a small website owner can repeat.

For teams that maintain many small sites, label each note with the date, hostname, intended visitor URL, and the exact setting that was checked. Plain notes are more useful than memory because DNS, HTTPS, redirects, and cache settings are often revisited months later. When the next symptom appears, the note explains why a record was proxied, why a hostname redirects, and which service owns the certificate.

• Write down the exact hostname being tested, including whether it is root, www, a subdomain, or a provider verification hostname.
• Record whether the hostname should be proxied or DNS-only; do not use orange-cloud mode for mail, SSH, FTP, or unsupported service hostnames.
• Check HTTPS separately from DNS. A correct IP address does not prove the certificate, SSL mode, or redirect path is correct.
• Keep one canonical target for visitors and use the related root-versus-www guide before adding multiple redirect rules.
• After each edit, wait long enough for the relevant layer, then retest the same input instead of jumping to a different symptom.

When the route is finished, continue through the same-site sequence: DNS records, SSL modes, proxied versus DNS-only, root versus www, and the launch checklist. That sequence keeps the work public and user-facing while avoiding hidden operational assumptions.