.page Locks HTTPS in the Root Zone—Not in Your Headers

Most TLD guides open with a pricing table and a list of imaginary URLs. The old stub for .page did exactly that: product.page for launches, janedoe.page for portfolios, event.page for weddings—placeholder grammar dressed up as “notables.” Mid-2026 HTTP checks tell a different story. The suffix’s only hard, verifiable product decision is security baked into the root zone: every .page hostname is on Chromium’s HSTS preload list before your registrar sends the welcome email. Browsers refuse plain HTTP on the first request. You do not submit hstspreload.org. You do not toggle it off.

That architectural choice—not the marketing line about “single-purpose pages”—is what separates .page from .com. The rest is thinner: roughly 62,000 registrations in mid-2026, ~51% parked at Squarespace Domains II LLC, and a handful of live “canvas” products (mmm.page, front.page, byline.page) that Google Registry itself still cites. What follows throws out the daily-TLD template, deletes the Mad Libs, and follows receipts: Charleston Road lineage, launch calendar, TLD-wide TLS mechanics, verified roofs, zone math, premium pricing spread, and one ownership question about whether your public face is one screen or a site with rooms.

Fifth open TLD—and four months behind .app

.page is operated by Charleston Road Registry Inc., Google’s ICANN registry subsidiary, with Google Inc. as the registry backend in IANA records. Google announced it as their fifth open top-level domain on 20 July 2018 (launch details):

• 27 Aug – 2 Oct 2018 — Sunrise for Trademark Clearinghouse marks.
• 2–9 Oct 2018 — Early Access Program (EAP): five fee tiers, highest on 2 Oct 16:00 UTC, stepping down daily until GA (EAP tier times). Premium left-sides carried separate recurring premiums independent of EAP.
• 9 Oct 2018 onward — General Availability.

Google’s 2 October 2018 blog post (Start a new .page today) framed .page alongside .app (public launch May 2018) as part of moving the web toward HTTPS everywhere. Same registry house, same HSTS playbook—different English noun on the right.

Positioning copy on get.page sells “your next chapter online” for entrepreneurs, publishers, authors, and students. Semantically, page reads as one surface in URL grammar—the opposite of site, blog, or store. That is positioning luck, not a technical page-count limit. Nothing stops you from building multi-route apps on .page; the suffix just promises a scrollable public face.

TLD-level HSTS: what actually happens on first visit

For a typical .com, HTTPS is your job: buy a cert, redirect HTTP, optionally submit to hstspreload.org, wait weeks for Chromium releases. For .page, the entire TLD was preloaded before GA. Porkbun’s registry KB and Google’s Build Securely campaign state the consequence plainly: no valid TLS on the hostname → the browser will not load the site, often with an “HTTP is disabled for this domain” class error. This is not “SEO prefers HTTPS.” It is hardcoded client behavior.

Implications registrants miss:

1. You cannot accept HTTP on the apex or any subdomain covered by the TLD policy. Staging at http://dev.yourbrand.page fails unless that host serves valid HTTPS.
2. Removal is not a registrar toggle. Individual .page names inherit TLD preload; this is not the same as enrolling one domain you can later delist.
3. Parking and landers must be HTTPS-native. Aftermarket pages work—but only with certificates. In 2026 that is normal elsewhere; here it is mandatory from byte zero.
4. Google Registry also preloads sibling open TLDs including .app, .dev, .day, and newer strings listed on safe.page (.ing, .meme, .zip, etc.). Picking .page is picking Charleston Road’s security bundle, not a unique crypto feature.

The old stub treated HSTS as a bullet under “SEO and AIO.” That inverted the product. TLS in the root zone is the product. Rankings still depend on content and links—John Mueller’s standing guidance applies: new gTLDs are treated like other gTLDs; keywords in the TLD do not confer ranking advantage. Delete any “AI engines cite .page normally” filler; models cite pages with authority, not suffixes.

Verified roofs—and the Mad Libs to delete

Google Registry’s get.page carousel is the primary source for early adopters—not registrar listicles. Mid-2026 HTTPS checks still return HTTP 200 on mission:

mmm.page — Drag-and-drop “internet canvas” for link-in-bio, portfolios, moodboards, and collage sites; TechCrunch (January 2024) reported 50,000+ users without VC; Vercel’s case study cited 30,000+ custom domains on the platform infrastructure. The product lives on .page and sells custom domains as an upgrade—proof the suffix can anchor a hosting layer, not just a parked left-side.

byline.page — Multiplayer creative writing: each author sees only one line before adding their own.

front.page — Mobile-first publishing for niche content creators (not frontpage.page, which does not resolve usefully).

funnies.page — Daily comics newsletter surface.

volition.page — Goal and progress tracking (site metadata still shows a 2020-era build—alive, if dated).

safe.page — Google Registry’s Build Securely education campaign—meta proof the registry eats its own HSTS cooking.

get.page — Registry marketing and registrar routing (200).

Trash the stub’s fiction: product.page, janedoe.page, feature.page, yourname.page, event.page as “notables.” Those are Mad Libs, not mid-2026 case studies. If you cannot open a living homepage that matches the claim today, you do not have a notable—you have brochure filler.

~62k names: niche zone, Squarespace concentration

nTLDStats in mid-2026 counted 62,027 .page registrations (~0.13% of tracked new gTLDs)—nowhere near industrial siblings .app (~1.82M) or .dev (~832k) on the same dashboard’s top-30 table. The TLD does not appear in the global top-30 new gTLD list at all.

Distribution is skewed: Squarespace Domains II LLC held 31,845 names (51.34% share). Namecheap (~5.4%), GoDaddy (~2.6%), Porkbun (~2.6%), Cloudflare (~2.0%) trail far behind. Interpreting that skew matters: a huge slice of .page is Squarespace bundle inventory—domains registered because a website plan included a first-year custom name, not because buyers hunted the suffix for canvas aesthetics. India’s nTLDStats breakdown ranks .page #5 among new gTLDs locally (~9,710 names, ~6.74% share)—regional adoption outruns global rank, similar to other Google Registry strings in that market.

W3Techs’ crawls still place .page at ~0.0% of active websites—zone size ≠ visible web share. nTLDStats also shows 13,643 “unprocessed” names and 803 upcoming deletes—churn on a small base.

ICANN’s Google Registry confusion-avoidance plan for open TLDs including .page restricts ISO-3166 alpha-2 labels (e.g. in.page, io.page) from being resold as third-level landlords—relevant if you wanted a {country}.page resale scheme.

Pricing: retail spread and premium cliffs

Standard retail in mid-2026 still clusters low-teens. TLD-List spans registration quotes from about $8.13 to six-figure premium tiers ($128,887.18 top quote on the aggregator snapshot); regme.org listed Porkbun near $8.73 new/renew and Namecheap near $11.16 / $13.16. Cloudflare’s at-cost shelf has historically sat near $8.18 plus ICANN fee. Google’s EAP announcement warned that premium prices apply to renewals, not just first year—always confirm tier in the cart.

| Tier | Typical USD (mid-2026) | |------|------------------------| | Standard registration (1 yr) | $8–$16 | | Standard renewal (1 yr) | $9–$18 | | Transfer | Often ~1 renewal year | | Registry premium (short/dictionary) | Hundreds to six figures + premium renewals |

Model three years at renewal, not the intro banner. A $8 first year that renews at $15 is still cheaper than .com premium theater—but dictionary left-sides on Google Registry often behave like inventory, not standard carts.

mmm.page and the canvas thesis

If .page has a living use case beyond Squarespace bundles, mmm.page is the exhibit. Founder XH built a Clippy-meets-collage editor (Show HN, 2021) where users overlap GIFs, text, and embeds without grid-locking—deliberately non-prescriptive aesthetics. Custom domains monetize through Vercel’s platform infrastructure because HSTS-at-TLD plus automated TLS removed months of DIY certificate work—exactly the pain Google Registry marketed in 2018.

That does not mean your firstname.page inherits mmm’s vibe or traffic. It means the suffix can host one-screen expressive surfaces when the product matches the grammar. Multi-page SaaS, ecommerce catalogs, or corporate sites with six nav tabs usually fight the URL promise—use .dev, .app, or .com for rooms and hallways.

One screen—or a site with rooms?

Skip twin “who should / who shouldn’t” columns. Ask one product question:

Would a stranger correctly expect a single scrollable surface—and is that expectation the whole job?

If yes—link-in-bio, wedding one-pager, portfolio scroll, release landing, zine, status page, short-lived campaign—.page is semantically honest, and TLD-wide HSTS removes a whole class of launch mistakes. Budget renewals; verify premium tier; keep a memorable .com if offline customers must type you cold.

If you need blog archives, storefronts, docs trees, or app dashboards—the word “page” becomes a lie the first time someone clicks “About.” Prefer .blog for publishing roofs (.blog guide), .dev / .app for Google’s other HSTS siblings (.dev guide, .app guide), .me for personal brand (.me guide), or .com when the nav bar is the product.

Platform renters (Linktree, Carrd, mmm.page subpaths) still trade DNS ownership for speed. Owning you.page only wins when you will host and renew it.

Risks worth keeping

• Staging and legacy HTTP tooling break on first request—not after a redirect loop you can debug slowly.
• Small zone, low web crawl share — suffix recognition lags .com, .dev, and .app.
• Premium renewal surprises on short left-sides.
• Google as registry and Chrome’s HSTS list curator — philosophically noted; operationally governed by ICANN contract.

---

Need a one-screen hostname? Use our AI domain generator to compare .page, .app, .me, and .com availability side by side. For HTTPS beyond the TLD default, see SEO-Friendly Domain Names.