Connecting a Custom Domain

Connect your inblog-powered blog using a subdomain (e.g., blog.example.com) or subdirectory (e.g., example.com/blog), with guidance on DNS configuration.

Overview

The domain setup section may require developer assistance, particularly for DNS configuration or code implementation. Technical support sessions are available if needed.

You can connect your inblog-powered blog using one of two approaches:

• Subdomain (e.g., blog.example.com)
• Subdirectory (e.g., example.com/blog)

Where to add DNS records: DNS settings must be added where your domain is managed (e.g., Namecheap, GoDaddy, Cloudflare), not where your website is built (e.g., Webflow, Framer). If you built your site on Webflow but purchased your domain through GoDaddy, add the DNS records in GoDaddy.

Subdomain Setup

In the Custom Domain settings, select Subdomain and enter your desired subdomain.

Click Start connection to receive DNS configuration instructions. Update DNS settings through your domain provider, and your subdomain will connect within 5 minutes.

If your DNS provider rejects the CNAME value: some providers (e.g., Gabia) require the value to be a fully qualified domain name and show an error such as "the value must end with a dot (.)". In that case, add a trailing dot to the exact value inblog gave you. For example, if inblog shows abc123.vercel-dns-016.com, enter abc123.vercel-dns-016.com.. Other providers (e.g., Imweb) expect the value without the trailing dot. Follow the format your provider asks for.

Subdirectory (Sub-folder) Setup

"Subdirectory connection is currently supported for websites on Next.js, Vercel, AWS Amplify, Cloudflare, Framer, and Webflow."

Supported platforms include:

• Next.js: Supported, except for static export
• Vercel / AWS Amplify: Supported as hosting platforms
• Cloudflare: Supported when you can manage the hostname's Zone, Worker, and Routes in your own Cloudflare account, and the existing website works while its DNS record is Proxied. Seeing Cloudflare in response headers or an IP lookup alone does not meet this requirement.
• Framer / Webflow: Supported via reverse proxy using Cloudflare

Before using the Cloudflare guide: continue only when the existing website already works while Proxied, and the target path (for example, /blog) is unused or its existing content and URLs have been migrated. A DNS only record, a SaaS website builder, another CDN or proxy, or an account that cannot manage the Cloudflare Zone and Worker Routes requires a separate review. If the hostname cannot remain proxied, use a subdomain connection instead.

The dashboard's connection guide also provides step-by-step setup for AWS CloudFront, Cloudflare, and Nginx.

If your environment isn't in that list (Apache, for example), choose Other / Contact us. Any web server that can proxy a specific path to an external origin can be connected through a custom reverse proxy — reach out over chat and we'll confirm feasibility with you.

Select Subdirectory in the Custom Domain settings and enter your domain (e.g., example.com/blog). Click Start connection for the full setup guide. Note that subdirectory setup typically requires code implementation.

The "web infrastructure" picker doesn't change anything on inblog's side. It only decides which setup guide you see, so switching it later has no effect on a domain you've already connected.

If a CDN or proxy such as Cloudflare or CloudFront already sits in front of your web server (Apache, Nginx, and so on), pick that CDN regardless of the origin server. Handling the proxy rule where requests arrive first is simpler and leaves your origin configuration untouched.

AWS CloudFront Subdirectory Setup

To configure inblog in a sub-directory using AWS CloudFront, check the following setup steps.

1. Use the distribution that serves your main website, or create a new distribution if CloudFront is not configured yet.
2. Set Distribution name to inblog proxy and Domain to example.com.
3. Set Origin type to Other, Custom origin to proxy.inblog.dev, and Origin path to /{subdomain}.
4. Set the origin request policy to Managed-AllViewerExceptHostHeader so CloudFront does not forward the viewer Host header to proxy.inblog.dev.
5. Create a CloudFront Function for URI rewriting and paste the following code.

function handler(event) {
  var request = event.request;
  var uri = request.uri;
  var basePath = "/blog";

  if (basePath === "/") {
    return request;
  }

  if (uri === basePath) {
    request.uri = "/";
    return request;
  }

  if (uri === basePath + "/") {
    request.uri = "/";
    return request;
  }

  if (uri.startsWith(basePath + "/")) {
    request.uri = uri.substring(basePath.length);
    return request;
  }

  return request;
}

6. Add behaviors for /blog, /blog/*, and /robots.txt.
7. Publish the function to Live, then attach it to the Viewer request event for all three behaviors.

After deployment, verify the following URLs from your terminal.

curl -I https://example.com/blog
curl -I https://example.com/robots.txt

CloudFront Returns a 502 Error

First, make sure you did not leave Origin path empty. A subdirectory connection uses Custom origin proxy.inblog.dev together with Origin path /{subdomain} — not a separate CNAME value.

If your settings match that and 502 errors persist, check the following in order. One of these is missing in most cases.

1. All three behaviors — /blog, /blog/*, and /robots.txt — use the proxy.inblog.dev origin.
2. All three behaviors use the Managed-AllViewerExceptHostHeader origin request policy. If the viewer Host header is forwarded, the origin cannot serve the request.
3. The CloudFront Function is published to Live — saving it is not enough.
4. That function is attached to the Viewer request event on all three behaviors.
5. The distribution has finished deploying (Deployed), including your most recent change.

If everything above checks out and the 502 continues, send us the output of the three commands below. Comparing a request through CloudFront against a request straight to the origin lets us isolate the cause.

curl -I https://example.com/blog
curl -I https://example.com/robots.txt
curl -I https://proxy.inblog.dev/{subdomain}

My Subdirectory Blog Returns ERR_TOO_MANY_REDIRECTS

The blog path is stuck in a redirect loop and won't load at all. The cause is usually a /blog rule on your own site. These two are the most common.

1. It must be a rewrite, not a redirect

Passing /blog to inblog requires a rewrite (reverse proxy) — the address stays the same and your server answers with inblog's response. A redirect makes the /blog request point back at /blog, which loops forever.

/blog       →  https://proxy.inblog.dev/{subdomain}
/blog/:path*  →  https://proxy.inblog.dev/{subdomain}/:path*

2. The www form differs between inblog and your site's canonical address

If your site treats example.com (non-www) as canonical but the address registered on inblog is www.example.com/blog, the www and non-www redirects bounce off each other. Settle on one form.

• Register the address on the inblog Domain tab in the same form your site uses as canonical.
• Apply www → non-www consolidation in your host's domain redirect settings, in one direction only — not as a /blog-specific rule.

How to tell which side is at fault

Compare the response headers for each address. If the last command returns 200, inblog is fine and only your site's redirect rules need fixing. If it returns a 3xx instead, the inblog side needs checking — send us that output over chat.

curl -I https://example.com/blog
curl -I https://www.example.com/blog
curl -I https://proxy.inblog.dev/{subdomain}

The warning "Your domain is still connected, but the latest reverse proxy check did not return the expected response" on the domain card can have the same cause. It also appears for firewall blocks or transient failures, and clears itself on the next check once the proxy rules are working.

Will Subdirectory Setup Overwrite My Existing robots.txt?

The setup guide includes a rule that proxies /robots.txt to inblog alongside your blog paths (/blog, /blog/*). That rule exists for sites that don't already have a robots.txt. If you already maintain your own, don't apply it as-is.

A domain has only one robots.txt, served from the root and applied to every path beneath it. Proxying /robots.txt means inblog's file answers instead of yours, so any Disallow rules you had stop applying.

If you already have a robots.txt, pick one of these:

1. Drop just the /robots.txt rule (recommended)

• Keep the proxy rules for your blog paths (/blog, /blog/*) and remove only the /robots.txt rule.
• Add your blog's sitemap to your existing robots.txt:

Sitemap: https://example.com/blog/sitemap.xml

• Confirm none of your existing Disallow rules block the blog path (/blog).

2. Keep the proxy and edit robots.txt inside inblog

• Go to Settings → SEO Tools → Robots.txt in the dashboard (paid plan, after your custom domain is connected).
• Paste your existing rules there and keep the blog sitemap line. Whatever you save is served as the response for example.com/robots.txt.
• The editor comes pre-filled with the default inblog generates (allow all crawlers, plus sitemap URLs). Clear it completely and save to go back to that default.

You don't need to maintain the sitemap yourself. With the proxy in place, example.com/blog/sitemap.xml is regenerated by inblog whenever you publish or edit a post. There's no xml file to upload or refresh on your side.

Subdirectory and Google Search Console

When you connect a subdirectory (e.g., example.com/blog), your blog traffic is included under the existing root domain Search Console property. If you want to analyze blog-only data separately, you can add an additional URL-prefix property:

• Property type: URL prefix
• URL: https://example.com/blog

This separate property also requires its own HTML tag verification. Add the meta tag for this property in the inblog dashboard under Design tab → Advanced settings (Code injection).

What does (not verified) mean in the blog list?

After adding DNS records, the domain status in the inblog dashboard's blog list may show (not verified). This means inblog has not yet confirmed your DNS records. Common reasons:

• The DNS records haven't been added yet, or the values are incorrect.
• DNS propagation takes up to 24–48 hours after changes are made.

Once the status changes to (verified), DNS confirmation is complete. The domain may take a few more minutes to become fully accessible.

The Domain tab says "Issuing SSL certificate". Should I just wait?

In most cases, yes. Unless you have set a CAA record on the domain, there is nothing left for you to do. "Issuing SSL certificate" appears only after your DNS records have been confirmed, when the HTTPS setup is the last remaining step. It means your records already passed validation.

For subdomain and root-domain connections, the Domain tab shows one of four connection states:

Subdirectory connections show a different set of three states instead: Reverse proxy setup required, Checking reverse proxy connection, and Connected.

DNS changes can take up to 24–48 hours to propagate, and the site may take a few more minutes to open after the certificate is issued.

• If you have set a CAA record on the domain, check it as well — it can block certificate issuance.
• If it stays on "Issuing SSL certificate" for more than a day, send us the address you're connecting along with a screenshot.

The domain card says "Could not find nameservers for this domain."

inblog looks up the nameservers of the root domain behind the address you entered (e.g., blog.example.com → example.com) so it can tell you which DNS service to add records to. This warning means that lookup returned nothing. Check the following:

• The domain is spelled correctly.
• The domain is actually registered and has not expired.
• Nameservers are assigned at your domain registrar (they can be empty right after purchase).

This warning only reflects the lookup we use to tell you which DNS service to use — it does not block verification. If the domain genuinely has no nameservers assigned, records you add won't resolve either, so finish the nameserver setup at your registrar first. If the connection proceeds normally after you add the records, you can ignore this warning.

It works for me, but others can't open my blog

Sometimes the domain status shows "Verified" and the blog loads fine for you, but people you share the link with can't reach it. This usually isn't a domain configuration problem — the network they're on (home Wi-Fi, mobile carrier, office network) still has the old state in its DNS cache. DNS changes roll out at different speeds on different networks for up to 24–48 hours, so public DNS can already be correct while some networks still fail to resolve the address.

What to do:

• Share the full address (e.g., https://blog.example.com) rather than a partial one.
• Ask anyone who can't reach it to try mobile data instead of Wi-Fi, or to retry a little later.
• If it still fails on a specific network after 24–48 hours, send us the exact address used and a screenshot of the error from that environment.

Can I Move a Subdomain Blog to a Subdirectory?

Yes. Switch the connection type to Subdirectory on the Domain tab and register the new address (e.g., example.com/blog). Note that a blog uses one connection type at a time, so blog.example.com and example.com/blog can't run side by side.

What follows automatically

• Post slugs don't change. Only the host and leading path differ, so there's no per-post work.
• Canonical URLs, the sitemap, RSS, and category/author page addresses switch to the new address once the new connection is verified (caches may take a few minutes to catch up).
• API and CLI automations (Make, Zapier, n8n, and so on) are unaffected. An API key is tied to the blog itself rather than to the custom domain, so changing the connection type doesn't break it.

What you need to handle yourself

• Set up the 301 redirect from your old custom subdomain (blog.example.com) yourself. Once it's disconnected, inblog no longer answers on that host, so add a blog.example.com/{slug} → example.com/blog/{slug} rule wherever you manage the domain or hosting. Since slugs are unchanged, a single rule that swaps the host and prefixes /blog is enough.
• Point blog.example.com's DNS record away from inblog first, or the redirect rule won't take effect — with the old CNAME still in place, requests keep heading to inblog.
• The automatic redirect from the default inblog domain (xxx.inblog.io) to your custom domain is designed around subdomain and root-domain connections. It may not apply right after a switch to a subdirectory, so if default-domain URLs are indexed, check the actual response once the switch is done.

Will the blog go down during the switch?

Until the new proxy setup is verified, the blog stays reachable on the default domain (xxx.inblog.io), then switches over automatically once verification completes. Your existing website isn't touched beyond adding the /blog path rule.

Search engines need time to re-index a changed address. The 301 redirect from the old address is what carries your indexing and traffic across, so don't skip it.

No Domain? No Problem.

If you lack a custom domain, continue using the default blog domain (e.g., example.inblog.io) by selecting the "I don't own a domain" option during setup. You can upgrade to a custom domain at any time.

How do I add a "Blog" tab to my main website's navigation?

inblog does not control your main website's navigation menu. To add a blog link, update the navigation in the tool used to build your main site (e.g., Webflow, Framer, WordPress, or your CMS).

Use your inblog blog address as the link target:

• Subdomain: https://blog.example.com
• Subdirectory: https://example.com/blog

Before connecting a custom domain, you can temporarily use the default inblog domain, e.g., https://example.inblog.io.

How do I make the blog header logo link back to my main website?

In the inblog dashboard, go to Design tab → Header. There you can set the logo image and the URL visitors are taken to when they click it. Enter your main website URL to redirect visitors to your homepage.

Last updated 2026-08-05