A content identifier is useful for identifying a website release, but it is not an address most visitors will remember. A domain name solves the human side of that problem. Connecting the two requires care because a readable name, an HTTP gateway, a TLS certificate, and a retained release are separate pieces of the delivery path. Changing one does not automatically configure the others.

This guide follows a publisher who already has a working IPFS release and wants to share it under a familiar domain. The goal is a predictable deployment process: prepare the new release, verify it, change the naming layer, and keep a recovery path. Begin with the IPFS hosting architecture overview if these components are still unfamiliar.

Understand the two addresses

A CID identifies content. A domain name is a human-readable name whose configuration can change. A useful release process preserves that distinction: keep the CID as a record of an approved build, and use the domain as the public entry point to whichever release is currently approved.

Do not treat the domain as evidence that the browser has independently verified the underlying content. A conventional HTTPS connection authenticates a connection to the domain's server according to the browser's trust model. The way content is retrieved and verified depends on the client and gateway architecture. Be precise about that boundary when describing your site.

A sensible operational record contains both addresses. This lets someone investigate whether a failure belongs to the intended content or to the naming and delivery path around it.

DNSLink uses a DNS TXT record to associate a name with an IPFS path or an IPNS name. For a direct release mapping, the record has the general form dnslink=/ipfs/ followed by the release's actual root CID. The TXT record is associated with a hostname prefixed by _dnslink.

For example, the record name for this site's domain would be _dnslink.ipfswebsite.com. The value must use the CID of the release you actually intend to publish; do not copy an abbreviated identifier from a screenshot. The official custom-domain and DNSLink guide explains the distinction between signaling a CID and serving a website directly over HTTPS.

That distinction is the key to avoiding a common misunderstanding. Adding the TXT record does not, by itself, cause every ordinary browser to retrieve the website from IPFS.

Decide how HTTPS visitors arrive

A visitor who types your domain into a conventional browser still needs a working HTTPS delivery route. You can operate a compatible gateway behind a reverse proxy, or serve the same static release through conventional hosting while publishing its DNSLink mapping separately. The operational choices differ, even when the website files are identical.

Write the chosen arrangement in one sentence. For example: the public domain serves the tested static build, while DNSLink signals the corresponding retained IPFS release. That sentence is more useful than a vague claim that the website is completely decentralized.

Check domain routing, certificate handling, and the gateway's supported configuration before making changes. Avoid assuming that a DNS provider's proxy mode or a hosting provider's custom-domain feature behaves the same way as another provider's implementation.

Choose the right gateway context

An HTTP URL's origin matters to browser storage, permissions, and script isolation. Sites served beneath different paths of the same hostname can share an origin. For application interfaces, plan a dedicated origin through an appropriate subdomain or DNSLink gateway arrangement rather than treating every public path gateway as interchangeable.

This is particularly important when your frontend connects to a wallet or stores preferences. Hosting a static bundle does not remove ordinary browser-security questions. Document which origin your application expects and what happens when the same files are opened under another gateway's domain.

Our IPFS website dApp guide explains why frontend delivery and transaction authorization should be tested as separate layers. For a simple content site, the same origin review is still useful when you add scripts later.

Test paths before pointing the domain

Build a staging checklist that exercises a nested article, an image, a stylesheet, and a link back to the homepage. Test through the actual delivery pattern you intend to use. A domain-root site and a website mounted beneath a CID path can expose different mistakes in absolute and relative links.

Keep browsing links distinct from canonical metadata. Browsing links should keep a visitor within a coherent release. Canonical URLs should identify the preferred public version you want search engines to consider. Neither should be changed accidentally by a deployment script that performs a broad text replacement.

Also inspect redirects. A site can appear to work because every click quietly sends the visitor back to conventional hosting. That may be a deliberate architecture choice, but it is not evidence that the IPFS copy is self-contained.

Prepare the release before changing DNS

First build the new folder, add it to IPFS, and record its root CID. Then confirm that the intended retention arrangement has completed its work. Open the release through an independent retrieval route and run your navigation checks. Only after those checks pass should the public naming record change.

This ordering reduces the chance of advertising a release that has not become retrievable yet. Keep the old release retained while the new mapping is being adopted. Different resolvers and clients can observe updates at different times, so a transition period should be part of the plan rather than a surprise.

Record the previous and new values in a release log. Include the source revision and the person or automation responsible for the change. Do not place DNS management credentials in that log or in the public website.

Diagnose each layer separately

When a custom domain fails, start with a concrete observation. Does the hostname resolve? Does HTTPS establish successfully? Does the response contain the intended page? Can the same release be retrieved through another route? Does the nested stylesheet load? Each answer narrows the problem.

A command such as dig +short TXT _dnslink.ipfswebsite.com can inspect the published DNSLink value, but the result alone does not establish that HTTPS delivery is working. Likewise, a healthy homepage does not establish that every file in its release is available.

Save the time and exact error from a failed check. For content retrieval, distinguish a timeout from a missing path. For naming, compare the intended record with the observed record. Troubleshooting becomes much faster when the report identifies a layer rather than declaring IPFS broken.

Design a rollback that can be executed

A rollback should restore a known, available release. Save the previous CID and verify that its files remain retained before you need them. If your conventional host and DNSLink record are managed separately, document how to bring both back to the same release.

Exercise the rollback

Practice the process on a noncritical change. Someone other than the original developer should be able to identify the intended release and reverse the naming update. If rollback requires guessing which build directory was used, the release record is incomplete.

Do not confuse rollback with erasure. Old content may remain accessible wherever it was copied or retained. Review sensitive material before publishing rather than relying on a future pointer change to remove it.

Conclusion: names are part of the release system

A good IPFS custom-domain setup is not just a TXT record. It is a tested relationship among a readable name, a delivery route, an approved CID, and retained content. Keep those responsibilities explicit, change the public pointer last, and preserve a working rollback. With that discipline, a domain becomes a useful publishing interface instead of an extra source of uncertainty around every release.