Publishing a static website on IPFS means distributing a directory of files, not installing a server application on a blockchain. HTML, stylesheets, scripts, images, and other public assets can form a content-addressed release. A CMS can generate those files beforehand, but PHP execution, database queries, and private administrative interfaces do not run merely because their source files were uploaded.
This guide uses a small public website as an illustrative deployment. The objective is to produce a repeatable release, retain it intentionally, and give readers a practical way to access it. A custom domain is a separate naming and delivery decision. DNSLink can advertise which content identifier belongs to a domain, but it does not by itself configure an HTTPS website or provide storage.
Prepare a genuinely static output directory
Build the site into a dedicated directory containing only public files. Place an index document at the root and directory-based index documents for clean page URLs. Include required styles, scripts, and images. Remove unpublished drafts, environment files, private keys, database exports, and build credentials. Inspect the generated output rather than assuming the source repository's visibility rules carry over.
Test the directory with a local static server before adding it to IPFS. Visit more than the homepage: open a nested article, an image, a stylesheet, and a page linked from the footer. Confirm that navigation and article content work without a backend. If a feature requires an external service, decide whether it is essential and document that dependency instead of describing the entire application as self-contained.
Choose a gateway URL model early
Root-relative links such as /about/ work naturally when your website has its own origin, including a suitable subdomain gateway or custom domain. A path-based gateway adds an IPFS prefix before the site's files, so a root-relative link can escape the release directory. Directory-relative links can help in some configurations, but they must be generated consistently across nested pages.
Choose the URL model before auditing links. Do not fix only the homepage and assume every article will behave identically. Test CSS background assets, canonical links, script imports, and downloadable files as well as ordinary anchors. A static-site generator may need a base-path setting for path-gateway deployment. An origin-based setup often makes a conventional website easier to preserve without rewriting every root-relative reference.
Add the release with an IPFS client
With an initialized Kubo installation, you can add a public directory recursively. The following command is an example to run in your own prepared environment; site is the directory you have already reviewed. Record the root directory CID returned by the command, not just the identifier of an individual file.
ipfs add -r --cid-version=1 site
ipfs pin ls --type=recursive
Kubo's normal add behavior pins the added content locally. Verify the actual pin state and keep the node available if it is part of your retention plan. Record the client version and import settings alongside the release. Do not expect a later rebuild with different settings to reproduce the same identifier automatically. A content identifier describes an exact representation, not a human judgment that two sites look equivalent.
Add an independent retention arrangement
A local pin is useful, but a laptop that is offline cannot serve readers continuously. Arrange retention appropriate to the site's importance, using an operated node or a suitable pinning service. When asking another provider to pin by CID, the provider must be able to retrieve the material. Confirm completion instead of treating a submitted request as proof of availability.
Keep a local release copy and a record of where it is retained. Consider a second independently operated copy for material whose continued availability matters. Test retrieval after the original publishing machine is disconnected from the network. That test helps expose a workflow that only appeared distributed because every successful request was actually being served by the original node.
Verify the complete website
Retrieve the release through the intended reader-facing route. Confirm that the root CID corresponds to the package you approved, and inspect several nested pages. Check image dimensions, mobile navigation, and links between directories. Distinguish verification of the underlying content from simply trusting an HTTP response supplied by a preferred gateway.
A useful deployment record includes the root CID, release label, file manifest, import settings, and the result of independent retrieval testing. Keep this record outside a single service dashboard. Another operator should be able to recover the website using the saved package and instructions. Our IPFS content management guide explains why retained availability is separate from identifying the files.
Signal the release with DNSLink
The official custom domains and DNSLink guide distinguishes CID signaling from serving a site at a custom HTTPS domain. DNSLink uses a DNS TXT record to associate a human-readable name with an IPFS path. For the illustrative domain below, replace the bracketed value with your real root CID; the example is a configuration pattern, not a live site.
Name: _dnslink.docs.example.org
Type: TXT
Value: dnslink=/ipfs/<ROOT_CID>
Publishing this TXT record lets compatible tools discover the selected content address. It does not create an A or CNAME record, issue a TLS certificate, or operate a gateway. DNS propagation and caching also mean that readers may not all observe an updated pointer immediately. Keep the previous release available during transitions, according to your retention policy.
Configure direct HTTPS access separately
To serve the site directly at your chosen domain, use a hosting or gateway arrangement that explicitly supports your DNSLink and domain configuration. Follow that operator's current instructions for the necessary A or CNAME record and TLS setup. There is no universal gateway hostname that every publication should copy. Domain validation and HTTPS termination are part of the delivery service.
Check the public domain
Test the finished domain in a normal browser. Confirm the certificate, canonical URL, nested routes, redirects, and asset loading. Also retain a release-specific route so the current domain is not the only way to identify an edition. A custom domain improves usability, but the registrar, DNS provider, and gateway remain operational dependencies that deserve their own recovery plan.
Publish an update as a new release
Make the change in the source content, rebuild, review the public output, and repeat the add-and-retain process. Retrieve the new release before updating the preferred pointer. Record the relationship between the previous root CID and the replacement. A correction should be understandable as an editorial event, not merely as an unexplained change in a technical identifier.
Updating DNSLink changes which release compatible readers are directed toward. It does not rewrite the old release or guarantee removal of other copies. Preserve older public versions according to a deliberate retention policy. For a rollback, verify the selected earlier release is still available before pointing readers back to it. A saved identifier cannot serve as a backup when no one retains the corresponding data.
Keep web metadata coherent
Choose one preferred public domain for canonical URLs and social metadata. Use complete HTML pages, descriptive titles, meaningful internal links, and a sitemap that reflects the content you want indexed. A release-specific gateway address can remain useful for verification without becoming the preferred search-facing URL. Do not claim that IPFS hosting automatically improves rankings or discovery.
Check that RSS links point to the intended reader-facing pages and that images referenced by social metadata remain accessible there. A stale absolute URL can survive unnoticed inside a static export. Include these metadata checks in the same release audit as navigation and retrieval. They are ordinary publishing responsibilities even when the storage layer is decentralized.
Conclusion: publishing is more than uploading
A dependable IPFS website combines reviewed static files, repeatable import settings, explicit retention, verified delivery, and controlled updates. DNSLink handles one part of the naming problem; HTTPS hosting handles another. Keep those responsibilities separate and test recovery before relying on the workflow. Continue with the storage comparison to decide which material belongs in an actively maintained publication and which deserves a deliberate archival destination.
