Domains

Your Writizzy domain

By default, your blog lives at yourblog.writizzy.blog.

You choose your subdomain in Settings → Domains under "Blog Url".

Important: Avoid changing this frequently. It impacts SEO. Search engines see it as a new site every time you change it.

Custom domain

Want to use your own domain? Add it in the "Custom Domain" field.

Once saved, we'll show you the DNS records to configure at your domain registrar.

DNS setup

The DNS configuration depends on whether you're using a subdomain or an apex domain (root domain).

Using a subdomain (e.g., blog.yoursite.com)

Add a CNAME record with these values:

• Type: CNAME
• Name: Your full subdomain (e.g., blog.yoursite.com)
• Value: yourblog.writizzy.blog (replace with your Writizzy subdomain)

This is the simplest and most reliable option. CNAME records work perfectly for subdomains.

If you set up your custom domain before we moved blogs to writizzy.blog, your record points to yourblog.writizzy.com. It keeps working, there is nothing to change.

Using an apex domain (e.g., yoursite.com)

Apex domains (also called root or naked domains) require a different approach since CNAME records are not allowed at the root level according to DNS standards.

Option 1: ALIAS record (Recommended)

Many DNS providers support ALIAS records (also called ANAME or flatten CNAME). This is the best option as it works like a CNAME but for apex domains:

• Type: ALIAS (or ANAME)
• Name: @ (represents your root domain)
• Value: yourblog.writizzy.blog

Popular providers supporting ALIAS records: Bunny.net (ANAME), Cloudflare (flatten CNAME), Hetzner, DNSimple, DNS Made Easy, AWS Route 53, and many others.

Option 2: A record

If your DNS provider doesn't support ALIAS records, use an A record:

• Type: A
• Name: @
• Value: 78.47.126.97

Note: A records point to a static IP address. If our server IP changes in the future, you'll need to update this record.

Propagation time

DNS changes can take up to 48 hours to propagate globally, though it's usually much faster (often within minutes to a few hours).

You can verify your DNS configuration using online tools like DNS Checker or use the "Verify domain" button in your Writizzy settings.

That's it. Once DNS is configured and verified, your blog will be accessible on your custom domain.

Serving your blog under /blog

If you already have a website, you may want to use a subfolder e.g yoursite.com/blog.

It takes more setup, and you need to be able to configure your own hosting.

How to set it up

1. In Settings → Domains, tick "Use a /blog subfolder" and enter your domain.
2. On your own hosting, forward yoursite.com/blog/* to https://yourblog.writizzy.blog/blog/*.
3. Come back and verify. We call your address and check that it reaches your blog.

Keep the /blog prefix when you forward. It is what tells us which blog to serve, and dropping it breaks every page.

The path has to be /blog.

Configure your reverse proxy

Whatever tool you use, the rule has to:

• keep the /blog prefix
• send us yourblog.writizzy.blog as the host, not your own domain. Most tools do this by default, but some keep the original host, and then your requests reach the wrong site. If your blog answers with a page from somewhere else entirely, this is why
• pass along POST requests, so comments and newsletter sign-ups work
• pass along cookies, so readers stay signed in
• pass along the visitor's IP address in the X-Forwarded-For header, so your stats count real visitors instead of counting your own server over and over

See below for examples

One extra rule if you connect Bluesky

Connecting Bluesky also publishes your articles to the open network behind it (see Publishing to the open network). Apps on that network check that your domain and your publication belong to the same person by asking your domain for one file, at its root:

https://yoursite.com/.well-known/site.standard.publication

That file is served by us, so it needs a forwarding rule of its own, next to the /blog one:

yoursite.com/.well-known/site.standard.publication  →  https://yourblog.writizzy.blog/.well-known/site.standard.publication

The path is the same on both sides, so in most tools you only swap the host. Note that there is no /blog in it: the file has to sit at the root of your domain, that is what the standard asks for.

Skip it if you don't use Bluesky. If you do use it and skip it anyway, your articles still reach the network, but the apps that check ownership before showing a publication will not show yours.

Your robots.txt and sitemap

Using a subfolder means your blog is served from your own domain, so search engines see it as part of your site. Your robots.txt and sitemap are yours to manage.

Nothing you set in Writizzy reaches it, including the "Block AI bots" setting, which has no effect in this mode.

Two things worth checking in it.

First, that nothing blocks /blog. If a Disallow rule covers it, search engines skip the blog entirely.

Second, that your blog's sitemap is listed. robots.txt accepts as many Sitemap: lines as you want, so ours goes next to yours rather than replacing it:

Sitemap: https://yoursite.com/sitemap.xml
Sitemap: https://yoursite.com/blog/sitemap_index.xml

Turning it off

Remove the setting in Writizzy before removing the forwarding rule on your site. Otherwise your blog's public address points at a page that no longer exists.

Examples

nginx

location /blog/ {
    proxy_pass https://yourblog.writizzy.blog/blog/;
    proxy_set_header Host yourblog.writizzy.blog;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

location = /.well-known/site.standard.publication {
    proxy_pass https://yourblog.writizzy.blog/.well-known/site.standard.publication;
    proxy_set_header Host yourblog.writizzy.blog;
}

Apache

Needs the proxy, proxy_http and ssl modules.

SSLProxyEngine On
ProxyPreserveHost Off

<Location /blog>
    ProxyPass https://yourblog.writizzy.blog/blog
    ProxyPassReverse https://yourblog.writizzy.blog/blog
</Location>

<Location /.well-known/site.standard.publication>
    ProxyPass https://yourblog.writizzy.blog/.well-known/site.standard.publication
    ProxyPassReverse https://yourblog.writizzy.blog/.well-known/site.standard.publication
</Location>

ProxyPreserveHost Off is what sends us yourblog.writizzy.blog as the host. Apache adds the X-Forwarded-For header on its own.

bunny.net

In your pull zone, add an edge rule that fires on your blog URLs and points them at us:

• Condition: IF ANY — Request URL matches *://yoursite.com/blog/* and *://yoursite.com/blog*
• Override Origin URL → https://yourblog.writizzy.blog
• Add Request Header → Host = yourblog.writizzy.blog
• Override Cache Time → 0 seconds

Two conditions, because /blog on its own doesn't match /blog/*. Add *://yoursite.com/.well-known/site.standard.publication as a third one if you connect Bluesky: the origin and the host header are the same, and the path is passed through unchanged.

Set the cache time to zero and let us handle caching. Otherwise bunny.net serves the same page to everyone.

Vercel

In vercel.json:

{
  "rewrites": [
    { "source": "/blog/:path*", "destination": "https://yourblog.writizzy.blog/blog/:path*" },
    {
      "source": "/.well-known/site.standard.publication",
      "destination": "https://yourblog.writizzy.blog/.well-known/site.standard.publication"
    }
  ]
}

Netlify

In _redirects:

/blog/*  https://yourblog.writizzy.blog/blog/:splat  200
/.well-known/site.standard.publication  https://yourblog.writizzy.blog/.well-known/site.standard.publication  200

Cloudflare Workers

export default {
  fetch(request) {
    const url = new URL(request.url)
    const forwarded = url.pathname.startsWith('/blog')
      || url.pathname === '/.well-known/site.standard.publication'
    if (!forwarded) return fetch(request)
    url.hostname = 'yourblog.writizzy.blog'
    return fetch(new Request(url, request))
  }
}