How to Link a Web3 Domain to a Real Website
This is the guide for people who've already decided they want to point a Web3 domain at an actual website and want to understand how that really works, mechanically, rather than the marketing-page version. We'll walk through the ENS content hash approach specifically, since it's the most common and best-supported path, and then get into the practical reality that determines whether your visitors can actually reach the result.
The core idea: content hash records
A standard ENS name resolves to a wallet address by default — that's the "send crypto to alice.eth" use case. But ENS names support other record types too, including a content hash record. Instead of pointing to a wallet, this record points to a piece of decentralized content — almost always an IPFS or IPNS address. Any tool that understands both ENS and IPFS can use this record to fetch and display your site when someone requests your .eth name.
Step 1: Build your site as static files
IPFS hosting works best with static files — HTML, CSS, JS, images — rather than a server-rendered application that needs a live backend process. If your project site is a marketing page, docs, or a typical informational site (as opposed to a dynamic dApp interface with a live backend), this is usually a straightforward fit.
Step 2: Upload to IPFS through a pinning service
IPFS addresses content by its hash, not by a location, so "uploading" means adding your files to the IPFS network and getting back a content identifier (CID) that represents that exact version of your site. Because IPFS nodes don't guarantee to keep unpopular content around forever, most people use a pinning service — a provider that guarantees to keep your content available and reachable. Several established pinning services exist; compare current offerings and pricing directly since terms and providers change.
Step 3: Set the content hash on your ENS name
Once you have a CID for your uploaded site, you set it as the content hash record on your ENS name through the ENS app, using the wallet that owns the name. This is an on-chain transaction, so it costs gas — see our cost breakdown for what that can look like in practice. Every time you update your site's content, you'll need to re-upload to IPFS (getting a new CID) and update the content hash record again, which means another on-chain transaction and another gas fee.
Step 4: Understand how visitors actually reach it
This is the step most explainer articles gloss over, and it's the most important one for deciding whether this setup actually serves your audience. There are three realistic ways someone reaches an ENS-hosted site:
- A resolver-aware wallet browser extension (some wallet extensions support resolving .eth names directly to their linked content) — this covers a technically engaged sliver of crypto-native users, not the general public.
- A gateway service that translates your ENS name into a normal HTTPS URL, such as a public ENS gateway domain. This works in any browser, but requires the visitor to know and use that specific gateway URL rather than your plain
.ethname, and adds a dependency on that gateway staying operational. - A redirect from a normal domain you also own — for example, your standard
.comdomain redirecting to your content, with the ENS name kept as a secondary, wallet-facing identity rather than the primary way people find you.
None of these three paths get you the experience most people assume — typing yourproject.eth into Chrome and having it just load, the way a .com does. That capability doesn't exist in mainstream browsers today without extra software or a bridging service.
Why most Web3 projects still run a normal domain too
Given the above, the practical pattern we see (and recommend) across real projects is: run a standard domain and standard hosting as the actual, public-facing website — the one in your Twitter bio, your Discord, your paid ads, everywhere a general audience will click — and treat the Web3 domain as a complementary asset for wallet branding and crypto-native identity, optionally with a content hash pointing to a mirrored or IPFS-hosted version for the subset of visitors equipped to use it.
This isn't a compromise or a "not fully decentralized yet" apology — it's the sensible architecture given how the internet's infrastructure (browsers, DNS, certificate authorities) actually works today. Our guide on building a website for a Web3 project covers how to plan and structure that primary, standard-domain site properly. And if you're still deciding whether a Web3 domain is worth the effort at all, start with What Is a Web3 Domain and Do You Actually Need One?
Keeping it maintained over time
Linking a Web3 domain to content isn't a one-and-done task. Every time you update your site's content, you'll need to re-pin the new version on IPFS, get a fresh content identifier, and push an updated content hash transaction to your ENS name — which costs gas each time. It's worth deciding upfront how often your linked content actually needs to change; a static "about the project" page might get updated a handful of times a year, while anything resembling a frequently updated blog or dashboard is a poor fit for this approach and is better served by conventional hosting with an ENS-linked redirect pointing at it instead. Also keep an eye on whichever pinning service you use — if a pinning subscription lapses and no other node happens to have your content cached, the content your ENS name points to can become unreachable even though the domain itself is still valid.
Where we can help
We build the standard-domain half of this equation — the fast, reliable, mobile-first website that reaches every visitor regardless of what wallet or browser extensions they have — and we can advise on wiring up an ENS content hash or gateway redirect alongside it if you want the Web3 domain integrated too. See our pricing for what's included, or send us your project details and we'll scope it out.
FAQ
What is a content hash record on an ENS domain?
It's a record type on an ENS name that points to a piece of decentralized content, most commonly an IPFS or IPNS address, rather than to a wallet address. Wallet-aware browser extensions and gateways use this record to know what content to serve when someone requests the domain.
Will visitors using normal Chrome or Safari be able to see my ENS-linked site?
Only through a gateway or redirect service that translates the ENS name and its content hash into a normal HTTPS URL. Without that bridge, a stock browser has no built-in way to resolve a .eth name, so most everyday visitors won't reach the site directly by typing the .eth address.
What is IPFS and do I need to understand it to use ENS for hosting?
IPFS (InterPlanetary File System) is a peer-to-peer protocol for storing and addressing content in a decentralized way. To host a site there, you typically upload your built site files to IPFS through a pinning service, get back a content identifier, and set that identifier as your ENS content hash. You don't need to run IPFS infrastructure yourself, but you do need a pinning service to keep your content available.
Why would a project run both a Web3 domain and a normal domain?
Because a normal domain reaches every visitor by default, while a Web3 domain reaches only visitors with the right wallet extension or gateway. Running both means the project gets the branding and wallet-identity benefits of the Web3 domain without limiting who can actually load the site.
Disclosure: Some links in this article may be affiliate links — we may earn a commission at no extra cost to you. See our full affiliate disclosure.