Notion Sites review: publishing a workspace is not the same as having a website

Somebody on your team already wrote the thing in Notion. A product changelog, an onboarding doc, a public roadmap, an API reference. There is a "Share to web" toggle right there, so the instinct is obvious: toggle it on, add a domain, call it a website. For that exact case — content that already exists as a Notion page and just needs a public URL — this is close to the best option available anywhere, because the alternative is retyping the same document into a different tool for no reason.

The trouble starts the moment someone tries to use that same toggle to build something that was never a document in the first place — a homepage, a portfolio, a one-person business's public face. Notion Sites was not designed for that job, and the parts that matter for a real website — how the page renders, how fast it loads, how much of the design you can actually touch, whether search engines see it the way you meant — all show the seams. This review is about where those seams are, because "it looks fine when I'm looking at it in Notion" and "it works as a website" turn out to be different questions.

reach, if the page you actually need is one person's

Before getting into what Notion Sites is honestly good at, it's worth naming the tool built specifically for the job most people land on Notion Sites hoping to solve: one person, one page, live fast. reach takes a CV and a photo, asks a short set of questions, and generates a finished one-page personal site — the page itself is ready in about twenty seconds, and you can be live at a free yourname.joinreach.app subdomain in under two minutes. For a homepage, a portfolio, or a CV turned into a URL, that is the strongest answer available right now — faster than fighting a document tool into looking like a site, and built for exactly this job rather than adapted to it. reach does one specific job, a personal page, and does not do documentation or team wikis at all — but for "I need a page about me, today," it removes the blank-canvas problem that both Notion and every general builder hand you.

Route for one page	Price	Billing
reach subdomain	$0	included, live in under two minutes
reach Premium (custom domain, bought through reach)	$4.99	per month, or $49 per year
Notion Sites Plus + domain add-on	~$16	per month, both billed annually
Notion Sites Free (no custom domain)	$0	one notion.site subdomain only

Prices checked August 2026. The honest limitation on reach's side: it makes exactly one page. There is no sub-navigation, no second page for a separate project, no CMS to grow into later. If what you actually need is a small site that will eventually have more than one page, that constraint rules reach out just as clearly as it rules Notion in for documentation. We cover the fuller field, reach included, in the website builders worth paying for in 2026.

What gets published, and how it is rendered

A Notion page shared to the web is not converted into a static HTML document the way a traditional site generator would do it. It ships as the same client-rendered single-page application that powers the Notion app itself, pointed at a public URL instead of a private workspace. The first response a browser or a crawler gets is a mostly empty shell; the actual content — your headings, your text, your embedded databases — gets filled in afterward by JavaScript, once the page's block tree has been fetched and rendered client-side.

That matters for two audiences. For a human visitor on a reasonable connection, it is a brief flash of loading state before content settles in, not a dealbreaker. For anything reading the raw HTML without executing JavaScript — some social-share crawlers, some SEO auditing tools, and in the worst case a search engine's first pass — what shows up first is close to nothing. Modern Googlebot does execute JavaScript before indexing, so a Notion Sites page is not invisible to search the way it would have been a decade ago, but it is indexed on Google's terms and schedule, with an extra rendering step between publish and appear that a static page skips entirely.

The practical result is that a Notion Site behaves like a document viewer with a public URL, because that is exactly what it is. That is a fine trade for a doc. It is a real cost for a page whose entire job is to be found by people who do not already know it exists.

The small set of things you can actually change

Design control on Notion Sites is close to a fixed set of settings rather than an editor. You can choose a cover image, an icon, a handful of layout options for how a database renders, and — on paid plans — a few site-wide settings like a custom favicon and a site description. What you cannot do is move a block outside the constraints of Notion's own document layout, set custom typography beyond the built-in font choices, control spacing and rhythm the way a page builder lets you, or add a section that isn't one of the block types Notion already has. If you have used Notion at all, you already know the ceiling: whatever a Notion page can look like inside the app is what the public version looks like too, plus a cover photo.

For a changelog or a wiki this is close to a non-issue — nobody expects a docs page to have a hero section and a distinct visual identity, and consistency across pages is arguably the point. For anything meant to represent a person or a brand, the lack of design control shows up immediately: every Notion Site has a slightly recognizable family resemblance, the same way every un-customized Squarespace template used to.

The free plan strips further. Custom favicons, SEO title and description fields, themes and analytics are all listed as paid-plan features, so a free Notion Site is not just visually constrained — it is also invisible to the metadata that controls how it shows up when someone shares the link or when a search engine decides what to display in results.

Custom domains, and the tier that gates them

This is the sharpest edge in Notion's pricing, and it is worth stating precisely because it is easy to misread from the pricing page. Notion Sites costs Free $0, Plus $10 a month billed monthly or roughly $8 a month billed annually, and Business $20 a month or roughly $16 annually, per seat. A custom domain is not included in any of those — it is a separate add-on, priced at $8 a month per domain paid annually or $10 a month paid monthly, and it is only available to workspace owners already on a paid plan. So the actual floor for "my own domain on a Notion Site" is the Plus plan plus the domain add-on — roughly $16 a month, not the $8 the Plus tier alone might suggest. Prices checked August 2026.

The free tier gets one notion.site subdomain; paid plans get up to five. And the "Built with Notion" badge follows the same logic as the domain: it comes off only once the site is running on a custom domain, so it cannot be removed on Free, and it cannot be removed on Plus either unless you are also paying for the domain add-on. Two subscriptions to remove one badge is a specific and unusual structure among the builders in this comparison.

The honest use case: docs, changelogs, wikis

Set aside the personal-site comparison and Notion Sites looks completely different, because the honest use case is not "personal website" at all — it's internal documentation that needs an external audience some of the time. A public API reference that engineers already maintain as a Notion database. A changelog that product managers update the same way they update every other page in the workspace. An internal wiki where one section — a careers page, a public-facing FAQ — needs to escape the workspace without anyone rebuilding it in a second tool.

For all of those, the rendering weaknesses barely register. Nobody is trying to rank a changelog for a competitive search term; they're linking it directly from a product or an email. Nobody expects a wiki page to have bespoke typography. And the workflow win is real: the page is already maintained in Notion by people who work in Notion daily, so "publish" is a toggle rather than a migration — worth not undervaluing just because the same tool is a poor fit for a homepage. A lot of software gets judged as a website builder when it was actually built, quite well, as something else. If content needs regular updates and versioning matters, it's worth reading how the field compares more broadly in the blogging and content tools built into website builders.

Where load time actually lands you

We did not run a formal benchmark suite for this piece, but the architecture already tells the load-time story: a client-rendered single-page app has to ship its JavaScript bundle, initialize, fetch the page's block data, and then paint content, which is structurally slower on first load than a page that arrives as finished HTML. That gap is covered in more depth, across more tools, in page speed in website builders, tested — the short version here is that render-then-fetch architectures start behind static or server-rendered ones before a single design decision has been made, and no amount of image compression closes that gap on its own.

Who this is actually right for

If your content already lives in Notion and the audience is small, internal-adjacent, or arriving by direct link rather than search — a team's public changelog, a careers page linked from job listings, documentation your own product already points people to — this is close to the cheapest and least-friction way to put it on the internet, because the authoring tool and the publishing tool are the same tool and nobody has to learn a second system.

If you're building a homepage, a portfolio, or anything meant to be found by people who don't already have the link, the rendering model and the design ceiling both work against you, and the domain economics are worse than they look at first glance. That's a different job, and it has better-suited tools for it — reach if the page is a single person's CV turned into a site, or one of the general builders if the site needs to grow past one page. Notion Sites earns its place for the job it was actually built to do; it's worth not asking it to do the other one.