カスタムドメインの接続

サブドメイン（例: blog.example.com）、ルートドメイン、またはサブディレクトリ（例: example.com/blog）を使用してinblogで運用するブログを接続する方法と、DNS設定の手順を解説します。

概要

ドメイン設定のセクションでは、特にDNS設定やコードの実装において、開発者のサポートが必要になる場合があります。必要に応じて技術サポートのセッションをご利用いただけます。

inblogで運用するブログは、次の3つの方法のいずれかで接続できます:

• サブドメイン (例: blog.example.com)
• ルートドメイン (例: example.com)
• サブディレクトリ (例: example.com/blog)

DNSレコードを追加する場所: DNS設定は、Webサイトが作成された場所（例: Webflow、Framer）ではなく、ドメインが管理されている場所（例: Namecheap、GoDaddy、Cloudflareなど）に追加する必要があります。たとえば、Webflowでサイトを構築していてもGoDaddyでドメインを購入している場合は、GoDaddyでDNSレコードを追加してください。

ドメイン設定画面の場所

1. inblog.ai/dashboard にサインインします。ブログ一覧が表示されます。
2. 設定したいブログカードをクリックします。ドメインはブログごとに設定されるため、複数のブログを運営している場合は適切なブログが選択されているか確認してください。
3. 左側のメニューで、設定グループ見出しの下にある**ドメイン**をクリックします。（設定画面を開いてその中を探すのではなく、左側メニューのドメインを直接クリックしてください。）
4. ドメイン画面の上部で、サブディレクトリ、サブドメイン、またはルートドメインタブを選択し、アドレスを入力して接続を開始するをクリックします。サブディレクトリタブでは、使用しているWebインフラストラクチャを選択すると、対応するリバースプロキシのガイドがステップバイステップで表示されます。

ドメイン画面がグレーアウトして入力できない場合、そのブログはFreeプランです。カスタムドメインは、14日間の無料トライアルを含むTeamプランでご利用いただけます。

カードをクリックしたときに管理画面ではなく初期設定画面が開く場合は、そこでドメインの手順を進めてください。詳細はinblogを使い始めるの初期設定セクションを参照してください。

サブドメインの設定

カスタムドメイン設定でサブドメインを選択し、サブドメイン部分を除いたドメインを入力します。入力欄の前には固定された https://blog. が付いているため、ここに example.com と入力すると常に blog.example.com が接続されます。

1つのブログで使用できる接続方法は一度に1つのみです。そのため、blog.example.com と news.example.com を同時に運用することはできません。

接続を開始するをクリックすると、DNS設定の手順が表示されます。表示された内容とまったく同じレコードをDNSプロバイダーに追加してください。DNSの変更が伝播するまでに最大24時間かかる場合があり、inblogが自動的に接続を確認します。

ドメインを別の担当者が管理している場合は、DNSレコードの下にある依頼メッセージをコピーを使用して、開発者またはドメイン管理者へメッセージを送信してください。アドレスと、追加が必要なすべてのレコードが含まれています。

DNSプロバイダーがCNAMEの値を拒否する場合: 一部のプロバイダー（例: Gabia）では、値を完全修飾ドメイン名（FQDN）にする必要があり、「値の末尾をドット（.）にする必要があります」といったエラーが表示されることがあります。その場合は、inblogに表示された値の末尾にドットを追加してください。たとえば、inblogで abc123.vercel-dns-016.com と表示されている場合は、abc123.vercel-dns-016.com. と入力します。他のプロバイダー（例: Imweb）では末尾にドットを付けない形式が想定されています。ご利用のプロバイダーが要求する形式に従ってください。

www を同時に接続したり、2つ目のドメインを追加したりできますか？

できません。1つのブログに設定できるカスタムドメインは1つのみです。 サブドメインおよびルートドメインの接続では、inblogは登録されたアドレスに対してのみSSL証明書を発行します。登録されていないアドレスへのリクエストを受信してリダイレクトすることはできず、www 用の個別エイリアスフィールドも用意されていません。

www.example.com → example.com のリダイレクトが必要な場合（たとえば、Googleがすでに www バージョンを正規URLとして認識している場合など）:

• CNAMEのみで www をinblogに向けると、ERR_CERT_COMMON_NAME_INVALID などの証明書エラーが発生します — www は別個のホスト名であり、その証明書が存在しないためです。

• inblogには正規のアドレスのみを登録したままにして、ドメインまたはホスティングを管理しているプロバイダー（Cloudflare、Vercel、お使いのWebサーバーなど）のリダイレクトサービスに www を向けてください。そこで www の証明書を発行し、以下のように恒久的なリダイレクトを追加します。新しいルールには308を推奨します。正常に機能している301をそのまま維持するか、プロバイダーが301にのみ対応している場合は301を使用してください。308と301の違いと使い分けを参照してください:

  https://www.example.com/*  →  https://example.com/*
  

• ルール内でパスとクエリ文字列を保持してください。逆方向（example.com → www.example.com）も同様に機能します。

2つのアドレスを同時に運用したい場合（たとえば、blog.example.com を維持しながら example.com/guide も追加したい場合など）:

• 2つ目のブログを作成し、そこに2つ目のアドレスを接続してください。
• inblogではサブスクリプションとドメイン接続の両方がブログ単位であるため、1つのTeamプランのサブスクリプションで2つのブログをカバーすることはできません。新しいブログには独自のサブスクリプションが必要です。詳細はよくある質問（FAQ）を参照してください。
• 追加したいパスにすでにページが存在する場合（たとえば、現在 example.com/guide を開くと別のものが表示される場合）、サブディレクトリとして接続するとそのパスがinblogで置き換えられます。既存のページを別の場所に移動するか、空いているパスを選択してください。

サブディレクトリ（サブフォルダー）の設定

ダッシュボードには現在、Next.js、Vercel、AWS Amplify、AWS CloudFront、Cloudflare、Nginx、Webflow(ウェブフロー)、Framer(フレーマー) の設定ガイドが用意されています。使用している環境が一覧にない場合は、その他 / お問い合わせを選択してください。

サポート対象のプラットフォームは次のとおりです:

• Next.js: 静的エクスポートを除きサポート
• Vercel / AWS Amplify: ホスティングプラットフォームとしてサポート
• Cloudflare: ホスト名のZone、Worker、Routesをご自身のアカウントで管理でき、DNSレコードが Proxied（プロキシ済み）の状態で既存のWebサイトが動作する場合にサポート。レスポンスヘッダーやIPルックアップでCloudflareが表示されるだけでは、この要件を満たしません。
• Framer / Webflow: Cloudflareを使用したリバースプロキシ経由でサポート

Cloudflareのガイドを使用する前に: 既存のWebサイトが Proxied の状態で正常に動作しており、対象のパス（例: /blog）が未使用であるか、既存のコンテンツとURLの移行が完了している場合にのみ進めてください。DNS only（DNSのみ）のレコード、SaaS型のWebサイトビルダー、別のCDNやプロキシ、またはCloudflareのZoneとWorker Routesを管理できないアカウントの場合は、個別の確認が必要です。ホスト名をプロキシ状態に維持できない場合は、代わりにサブドメイン接続を使用してください。

ダッシュボードの接続ガイドでは、AWS CloudFront と Nginx のステップバイステップの設定手順も提供しています。

お使いの環境がその一覧にない場合（Apacheなど）は、その他 / お問い合わせを選択してください。特定のパスを外部オリジンにプロキシできるWebサーバーであれば、カスタムリバースプロキシを介して接続可能です。チャットでお問い合わせいただければ、実現可能性を確認いたします。

カスタムドメイン設定でサブディレクトリを選択し、ドメインを入力します（例: example.com/blog）。接続を開始するをクリックすると、完全な設定ガイドが表示されます。サブディレクトリの設定には通常コードの実装が必要である点にご注意ください。

「Webインフラストラクチャ」の選択は、inblog側には何も影響を与えません。 表示される設定ガイドを決定するだけなので、後から切り替えても、すでに接続済みのドメインには何の影響もありません。

CloudflareやCloudFrontなどのCDNやプロキシがすでにWebサーバー（Apache、Nginxなど）の前段に配置されている場合は、オリジンサーバーに関係なくそのCDNを選択してください。 最初に対処する場所でプロキシリクエストを処理する方がシンプルであり、オリジンサーバーの設定を変更せずに済みます。

ドメイン登録事業者（レジストラ）が「Webインフラストラクチャ」の一覧にありません

これは想定どおりです。この一覧は、ドメインを購入した場所ではなく、Webサイトが現在どこから配信されているかを尋ねています。 画面には「Webサイトがホストされているインフラストラクチャを選択し、以下の一致するガイドに従ってください」と表示されています。ここにはinblogがプロキシガイドを提供している環境のみが一覧表示されているため、NamecheapやGoDaddyなどのレジストラやDNSプロバイダーは選択肢にありません。

プロバイダーがドメインとWebホスティングの両方を提供している場合（Gabia、Cafe24など）、プロバイダー名ではなく、サイトが実際に稼働しているWebサーバー（通常はApacheまたはNginx）を基準に判断してください。Nginxであれば Nginx、Apacheや確認できない環境であれば その他 / お問い合わせ を選択します。

一覧に含まれるもの: NextJS、Vercel、AWS Amplify、AWS CloudFront、Cloudflare、Nginx、Webflow、Framer、および その他 / お問い合わせ。（韓国語のダッシュボードでは Cafe24 と Imweb も表示されますが、どちらを選択してもその環境ではサブディレクトリ接続が利用できない旨が表示されます。）

判断方法:

1. CloudflareやAWS CloudFrontなどのCDNまたはプロキシがサイトの前段にある場合は、オリジンサーバーに関係なくそのCDNを選択します。
2. そうでない場合は、サイトを実際に配信しているサーバーまたはプラットフォーム（Nginx、Vercel、NextJS、Framer など）を選択します。
3. サイトが一覧にないツール（WordPress、PHPなど）で構築されている場合は、構築ツールではなく稼働しているサーバーを基準に判断してください。Nginx上のWordPressであれば Nginx、Apache上のWordPressは一覧にないため その他 / お問い合わせ を選択します。
4. 判断がつかない場合は、その他 / お問い合わせ を選択してください。チャットが開き、一緒に実現可能性を確認できます。

制作会社や代理店がサイトを構築した場合は、次の2点を確認してください

1. 現在サイトを配信しているWebサーバーまたはホスティング（Nginx、Apache、Vercelなど）と、その前段にCloudflareやCloudFrontなどのCDNが配置されているか。
2. /blog および /blog/* に対してのみリバースプロキシ（リライト）ルールを追加できるか。リダイレクトではなく、リライトである必要があります。

サブドメインの場合もWebインフラストラクチャを選択する必要がありますか？

いいえ。Webインフラストラクチャの選択はサブディレクトリ接続の場合にのみ表示されます。

サブドメイン（blog.example.com）およびルートドメイン（example.com）の接続では、既存のWebサイトのサーバーには一切触れず、DNSレコードの追加のみを行うため、この画面は表示されません。インフラストラクチャ一覧が表示されている場合は、現在サブディレクトリの設定フローを進めています。

Webサイトのサーバーにプロキシルールを追加できない場合は、ドメインタブでサブドメイン接続に切り替えるのが通常は手早い方法です。ドメイン管理会社でDNSレコードを設定するだけで完了します。

AWS CloudFrontでのサブディレクトリ設定

AWS CloudFrontでinblogをサブディレクトリに接続するには、以下の設定手順を確認してください。

1. メインのWebサイトを配信している既存のディストリビューションを使用するか、CloudFrontがまだ設定されていない場合は新しいディストリビューションを作成します。
2. Distribution name を inblog proxy、Domain を example.com に設定します。
3. Origin type を Other、Custom origin を proxy.inblog.dev、Origin path を /{subdomain} に設定します。
4. CloudFrontが閲覧者の Host ヘッダーを proxy.inblog.dev に転送しないように、オリジンリクエストポリシーを Managed-AllViewerExceptHostHeader に設定します。
5. URI書き換えのための CloudFront Function を作成し、以下のコードを貼り付けます。

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

  var host = request.headers.host && request.headers.host.value;
  if (host) {
    request.headers["x-inblog-public-host"] = { value: host };
    request.headers["x-forwarded-host"] = { value: host };
  }
  request.headers["x-forwarded-prefix"] = { value: basePath };

  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. /blog、/blog/*、および /robots.txt のビヘイビアを追加します。
7. 関数を Live に発行（Publish）し、3つのビヘイビアすべてで Viewer request イベントに関連付けます。

デプロイ後、ターミナルから以下のURLを確認してください。

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

CloudFrontが502エラーを返す場合

まず、Origin pathを空のままにしていないか確認してください。サブディレクトリ接続では、個別のCNAME値ではなく、Custom origin proxy.inblog.dev と Origin path /{subdomain} を組み合わせて使用します。

設定が合致しているにもかかわらず502エラーが続く場合は、以下の項目を順に確認してください。ほとんどの場合、以下のいずれかが不足しています。

1. 3つのビヘイビアすべて（/blog、/blog/*、/robots.txt）で proxy.inblog.dev オリジンが使用されているか。
2. 3つのビヘイビアすべてで Managed-AllViewerExceptHostHeader オリジンリクエストポリシーが使用されているか。閲覧者の Host ヘッダーが転送されると、オリジンはリクエストを処理できません。
3. CloudFront Functionが Live に発行されているか（保存するだけでは不十分です）。
4. その関数が3つのビヘイビアすべての Viewer request イベントに関連付けられているか。
5. 最新の変更を含め、ディストリビューションのデプロイが完了しているか（Deployed）。

上記をすべて確認しても502が解消しない場合は、以下の3つのコマンドの出力をチャットでお送りください。CloudFront経由のリクエストとオリジンへの直接リクエストを比較することで、原因を切り分けることができます。

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

Apacheでのサブディレクトリ設定

Apacheはダッシュボードのインフラストラクチャ一覧に含まれていないため、その他 / お問い合わせを選択し、ご自身でApacheにリバースプロキシのルールを追加してください。example.com、/blog、{subdomain} は実際の値に置き換えてください。

まず、どのサーバーにルールを適用すべきかを確認してください。ドメインを購入した事業者（レジストラ／ネームサーバー）は、実際にサイトを配信しているマシンとは異なる場合がよくあります。ネームサーバーがホスティングプロバイダー側にあり、Webサイト自体はAWS EC2インスタンス上のApacheで稼働している場合、プロキシルールはホスティングプロバイダーのDNS画面ではなく、そのEC2インスタンスのApache設定に追加します。

サイトを配信しているVirtualHost（HTTPSを使用している場合はポート443のVirtualHost）に以下を追加します。

SSLProxyEngine On
ProxyPreserveHost Off

<Location "/blog">
  RequestHeader set X-Inblog-Public-Host "expr=%{HTTP_HOST}"
  RequestHeader set X-Forwarded-Host "expr=%{HTTP_HOST}"
  RequestHeader set X-Forwarded-Prefix "/blog"
</Location>

ProxyPass "/blog" "https://proxy.inblog.dev/{subdomain}"
ProxyPassReverse "/blog" "https://proxy.inblog.dev/{subdomain}"

ProxyPass "/robots.txt" "https://proxy.inblog.dev/{subdomain}/robots.txt"
ProxyPassReverse "/robots.txt" "https://proxy.inblog.dev/{subdomain}/robots.txt"

• ProxyPass "/blog" は /blog 配下のすべてのリクエストも転送するため、個別の投稿URLに対して個別のルールを設定する必要はありません。
• <Location "/blog"> 内の2つの RequestHeader 行は、訪問者が実際に閲覧しているアドレス（example.com）と、それが配信されているサブディレクトリ（/blog）をinblogに伝えます。プロキシによってこれらは除去されますが、分析ツールが投稿のURLを正しく属性付けするために必要となります。ルーティングではこれらを読み取らないため、除外してもブログの動作自体は継続します（mod_headers が必要です）。これらは必ず <Location> ブロック内に保持してください。VirtualHostのスコープに配置するとサイト上のすべてのリクエストに付加され、アプリケーションのURL構築方法が変わってしまう可能性があります。
• ProxyPreserveHost Off は非常に重要な行です。訪問者の Host ヘッダーがそのまま転送されると、inblogはリクエストを処理できません。これはCloudFrontの Managed-AllViewerExceptHostHeader ポリシーや、Nginxの proxy_set_header Host proxy.inblog.dev と同じ役割を果たします。
• すでに独自のrobots.txtを運用している場合は、/robots.txt のルールをスキップしてください。後述の**「サブディレクトリの設定によって既存のrobots.txtが上書きされますか？」**を参照してください。

必要なモジュールを有効化し、設定をテストしてリロードします。

Ubuntu / Debian

sudo a2enmod proxy proxy_http ssl headers
sudo apachectl configtest
sudo systemctl reload apache2

Amazon Linux / CentOS / RHEL（モジュールはすでに有効になっている場合が多いです）

sudo apachectl configtest
sudo systemctl reload httpd

以下の両方のURLが200を返すようになると、inblogのドメイン画面のステータスが自動的に接続済みに切り替わります。

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

VirtualHostファイルを編集する権限（sudo）がない場合は、サーバー管理者に上記の設定の適用を依頼してください。

サブディレクトリのブログで ERR_TOO_MANY_REDIRECTS が返される場合

ブログのパスがリダイレクトループに陥り、まったく読み込まれない状態です。原因は通常、ご自身のサイト側にある /blog のルールにあります。特に多いのは次の2点です。

1. redirect ではなく rewrite である必要があります

/blog をinblogに渡すには、**リライト（リバースプロキシ）**が必要です。アドレスはそのまま維持され、サーバーがinblogのレスポンスを返します。redirect になっていると、/blog へのリクエストが再び /blog を指し示し、無限ループが発生します。

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

2. inblogとサイトの正規アドレスの間で www の形式が異なっています

サイトが example.com（wwwなし）を正規として扱っているのに、inblogに登録されているアドレスが www.example.com/blog である場合、www と non-www のリダイレクトが互いに跳ね返り合います。どちらか一方の形式に統一してください。

• inblogのドメインタブには、サイトが正規として使用しているのと同じ形式でアドレスを登録します。
• ホスティング側のドメインリダイレクト設定において、一方向のみで www → non-www の統合を適用してください（/blog 固有のルールとしては適用しないでください）。

どちら側に問題があるかを切り分ける方法

各アドレスのレスポンスヘッダーを比較します。最後のコマンドが 200 を返す場合、通常はサイト側のリダイレクトルールを修正する必要があります（ただし、直後の注意点の例外を確認してください）。代わりに3xxが返される場合はinblog側の確認が必要です。その出力をチャットでお送りください。

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

ルールがすでに rewrite であり、proxy.inblog.dev が 200 を返しているにもかかわらずループが解消しない場合は、最初のコマンドのレスポンスにある location ヘッダーを確認してください。リクエストしたアドレスそのものに送り返されている場合、お客様側でこれ以上ルールを変更しても解決しません。ルールの編集を止め、その完全なレスポンスヘッダーをチャットでお送りください。

ドメインカードのドメイン接続確認の警告も同じ原因で発生することがあります。また、ファイアウォールによるブロックや一時的な障害によっても表示され、プロキシルールが正常に動作すると次回のチェック時に自動的に解消されます。メッセージごとの詳細については、ドメインカードの「接続確認の警告」の意味を参照してください。

昨日まで動作していたブログが今日404を返す場合

inblog側では何も変更していないのに、example.com/blog のすべてが404を返す状態です。最も一般的な原因は、サイトの再デプロイ、CDNの変更、またはファイアウォールの変更によって、/blog のプロキシルールが削除または上書きされたことです。

まず注意点: inblog側でドメインの接続を解除しないでください。 接続を解除して再追加してもサイトのプロキシルールは復元されず、ドメイン認証を最初からやり直すことになるだけです。

1. どの404ページが表示されているかを確認する

404ページの見た目によって、リクエストがどこまで到達したかがわかります。

2. リクエストを送信して問題のある側を切り分ける

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

2番目のコマンドが 200 を返した場合、inblog側は正常であり、サイト側の /blog ルールを復元するだけで済みます。2番目のコマンドも失敗する場合は、その出力をチャットでお送りください。

3. 最近変更された内容を振り返る

• サイトの再デプロイ — プロキシ設定がビルド出力に含まれていない場合、デプロイのたびにルールが消去されます。
• CDNやWAFルールの変更、または新しく追加されたボット保護ポリシー。
• Webサーバーの設定ファイルの置き換え、証明書の更新、その他同様のサーバー作業。

4. ダッシュボードの警告も確認する

設定 → ドメインに警告が表示されている場合は、以下のセクションで各メッセージの意味を説明しています。

ドメインカードの「接続確認の警告」は何を意味していますか？

inblogは、接続されたドメインが実際にこのブログを配信しているかを定期的に確認しており、期待されるレスポンスが得られない場合に設定 → ドメインの下にドメイン接続確認の警告を表示します。

警告が表示されているだけで訪問者がブログにアクセスできなくなるわけではなく、その後のチェックで成功すれば自動的に解消されます。それぞれのメッセージは異なる問題を示しています。

サブディレクトリの設定によって既存のrobots.txtが上書きされますか？

設定ガイドには、ブログのパス（/blog、/blog/*）とともに /robots.txt をinblogにプロキシするルールが含まれています。このルールは、まだrobots.txtを持っていないサイト向けに用意されたものです。すでに独自にrobots.txtを運用している場合は、そのまま適用しないでください。

1つのドメインにはルートから配信され配下のすべてのパスに適用されるrobots.txtが1つしか存在できません。/robots.txt をプロキシすると、お客様のファイルの代わりにinblogのファイルが応答するため、設定していた既存の Disallow ルールがすべて適用されなくなります。

すでにrobots.txtをお持ちの場合は、以下のいずれかの方法を選択してください:

1. /robots.txt のルールのみを除外する（推奨）

• ブログパス用のプロキシルール（/blog、/blog/*）はそのまま維持し、/robots.txt のルールのみを削除します。
• 既存のrobots.txtにブログのサイトマップを追加します:

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

• 既存の Disallow ルールがブログのパス（/blog）をブロックしていないことを確認します。

2. プロキシを維持し、inblog内でrobots.txtを編集する

• ダッシュボードの設定 → SEOツール → Robots.txtに移動します（カスタムドメイン接続後の有料プラン）。
• そこに既存のルールを貼り付け、ブログのサイトマップ行を維持します。保存した内容が example.com/robots.txt のレスポンスとして配信されます。
• エディタには、inblogが生成するデフォルト値（すべてのクローラーを許可し、サイトマップURLを含む）があらかじめ入力されています。すべてクリアして保存すると、そのデフォルト状態に戻ります。

サイトマップをご自身で管理する必要はありません。 プロキシが設定されていれば、投稿を公開または編集するたびにinblogによって example.com/blog/sitemap.xml が自動的に再生成されます。お客様側でXMLファイルをアップロードしたり更新したりする必要はありません。

サブディレクトリとGoogle Search Console

サブディレクトリ（例: example.com/blog）を接続すると、ブログのトラフィックは既存のルートドメインのSearch Consoleプロパティに含まれます。ブログのみのデータを個別に分析したい場合は、追加でこのブログのアドレスのみのプロパティを追加できます:

• プロパティタイプ: URL prefix
• URL: https://example.com/blog

この別個のプロパティにも、独自のHTMLタグによる確認が必要です。このプロパティ用のメタタグを、inblogダッシュボードの デザインタブ → 詳細設定（コードの挿入）で追加してください。

「接続を開始する」をクリックしても何も起きない、またはエラーポップアップで次のステップに進めない場合

これはDNSレコードの前のステップ、つまり接続処理自体が開始されない状態です。

リクエストが拒否された場合、ドメイン画面のアドレスフィールド付近またはポップアップにエラーが表示されます。再試行する前に以下の原因を確認してください。

以下の項目を順に確認してください。

1. 有料プランを利用しているか確認します。 カスタムドメインの接続は有料プランの機能であるため、Freeプランでは接続リクエストが拒否されます。
2. アカウントにドメイン接続の権限があるか確認します。 ドメインの接続や解除ができるのは、招待をすでに承諾している該当ブログのオーナー、管理者、または編集者のみです。
3. 短時間に何度も接続と解除を繰り返さないでください。 ドメインの接続／解除リクエストは1時間に10回までに制限されています。この制限を超えると、それ以降の試行はすべて拒否され先に進みません。設定ミスではありませんので、約1時間待ってから1回だけ再試行してください。
4. 入力形式を確認します。 サブドメインタブにはあらかじめ https://blog. が入力欄の前に付いているため、https:// や www を含めず example.com のみを入力します。サブディレクトリタブには、www.example.com/blog のように完全なパスを入力する必要があります。
5. （サブディレクトリ）入力したドメインがすでにインターネット上で名前解決できるか確認します。 接続を開始する前に、inblogは www.example.com/blog のドメイン部分（www.example.com）をパブリックDNSで検索します。そのホストにパブリックなA、AAAA、またはCNAMEレコードが存在しない場合、検索に失敗してリクエストは拒否されます。（www と入力した場合、レコードは www ホストに存在する必要があります。）

サブディレクトリ接続は、すでに公開されているサイトの上にブログを重ねる仕組みです。 このステップではDNSレコードの存在のみを確認しますが、その後のステップではそのサイト上にリバースプロキシルールを追加する必要があります。まず既存のサイトを指すDNSレコードを追加し、https://www.example.com が正常に開くことを確認した上で、接続を開始してください。Cloudflare上では、そのレコードが Proxied（プロキシ済み）になっている必要があります。

背後にサイトがまだ存在しない新しいドメインの場合、サブディレクトリ接続は適していません — プロキシルールを設定するサイトが存在しないためです。代わりに blog.example.com などのサブドメインを使用してください。サブドメインやルートドメインの接続はinblogが提供するDNSレコードを追加することで機能するため、既存のサイトは不要です。

ブログ一覧の （未認証） は何を意味していますか？

DNSレコードを追加した後、inblogダッシュボードのブログ一覧でドメインステータスが （未認証） と表示されることがあります。これは、inblogがDNSレコードをまだ確認できていないことを意味します。主な理由は以下のとおりです:

• DNSレコードがまだ追加されていないか、値が間違っている。
• 変更適用後、DNSの伝播に最大 24〜48時間 かかる。

ステータスが （認証済み） に変われば、DNSの確認は完了です。ドメインに完全にアクセスできるようになるまで、さらに数分かかる場合があります。

ドメインタブに「SSL証明書を発行中」と表示されています。そのまま待つべきですか？

ほとんどの場合、そのままお待ちください。 ドメインにCAAレコードを設定していない限り、お客様側で行う作業は残っていません。「SSL証明書を発行中」は、DNSレコードが確認された後、最後のステップとしてHTTPSのセットアップが行われているときにのみ表示されます。これは、レコードの検証がすでに合格していることを意味します。

サブドメインおよびルートドメインの接続では、ドメインタブに以下の4つの接続状態のいずれかが表示されます:

サブディレクトリ接続では、代わりに リバースプロキシの設定が必要、リバースプロキシの接続を確認中、接続済み の3つの状態が表示されます。

DNSの変更が伝播するまでに最大24〜48時間かかる場合があり、証明書が発行された後、サイトが開くまでにさらに数分かかることがあります。

• ドメインに CAAレコード を設定している場合は、それも確認してください。証明書の発行をブロックしている可能性があります。
• 「SSL証明書を発行中」の状態が1日以上続く場合は、接続中のアドレスとスクリーンショットをチャットでお送りください。

ドメインカードに「このドメインのネームサーバーが見つかりませんでした」と表示されます

inblogは、レコードを追加すべきDNSサービスを案内できるように、入力されたアドレスの背後にあるルートドメイン（例: blog.example.com → example.com）のネームサーバーを検索します。この警告は、その検索で何も返されなかったことを意味します。以下を確認してください:

• ドメインのスペルが正しいか。
• ドメインが実際に登録されており、有効期限が切れていないか。
• ドメインレジストラでネームサーバーが割り当てられているか（購入直後は空になっていることがあります）。

この警告は、使用すべきDNSサービスをご案内するための検索結果を反映しているに過ぎず、ドメインの検証自体をブロックするものではありません。ドメインにネームサーバーが本当に割り当てられていない場合は、追加したレコードも解決されないため、まずレジストラ側でネームサーバーの設定を完了してください。レコード追加後に接続が正常に進むようであれば、この警告は無視して問題ありません。

自分はアクセスできますが、他の人がブログを開けません

ドメインのステータスが**「認証済み」と表示され、自分ではブログが問題なく読み込めるのに、リンクを共有した他のユーザーがアクセスできないことがあります。これは通常、ドメイン設定の問題ではなく、相手の利用しているネットワーク（自宅のWi-Fi、携帯キャリア、オフィスのネットワークなど）の DNSキャッシュ に古い状態が残っていることが原因です。DNSの変更はネットワークごとに最大24〜48時間にわたって異なる速度で反映される**ため、パブリックDNSがすでに正しく更新されていても、特定のネットワークではアドレスの名前解決に失敗することがあります。

対処法:

• 省略したアドレスではなく、完全なアドレス（例: https://blog.example.com）を共有してください。
• アクセスできないユーザーに、Wi-Fiの代わりにモバイルデータ通信を試してもらうか、少し時間をおいてから再度試してもらうよう依頼してください。
• 24〜48時間経過後も特定のネットワークでアクセスできない場合は、使用した正確なアドレスとその環境でのエラーのスクリーンショットを添えてチャットでお問い合わせください。

サブドメインのブログをサブディレクトリに移行できますか？

可能です。ドメインタブで接続タイプをサブディレクトリに切り替え、新しいアドレス（例: example.com/blog）を登録します。ブログで使用できる接続タイプは一度に1つのみであるため、blog.example.com と example.com/blog を同時に運用することはできません。

自動的に引き継がれるもの

• 投稿のスラッグは変更されません。ホストと先頭のパスのみが異なるため、投稿ごとの作業は不要です。
• 新しい接続が認証されると、正規URL（canonical URL）、サイトマップ、RSS、およびカテゴリー／著者ページのアドレスが新しいアドレスに切り替わります（キャッシュの更新に数分かかる場合があります）。
• APIやCLIの自動化（Make、Zapier、n8nなど）には影響ありません。 APIキーはカスタムドメインではなくブログ自体に紐付いているため、接続タイプを変更しても機能しなくなることはありません。

ご自身で対応が必要な作業

• 以前のカスタムサブドメイン（blog.example.com）からの恒久的なリダイレクト（308を推奨）をご自身で設定してください。 接続を解除すると、inblogはそのホストでの応答を行わなくなるため、ドメインまたはホスティングを管理している場所で blog.example.com/{slug} → example.com/blog/{slug} のルールを追加します。スラッグは変更されないため、ホストを入れ替えて先頭に /blog を付加する単一のルールで十分です。
• まず blog.example.com のDNSレコードがinblogを向かないように変更してください。 そうしないとリダイレクトルールが有効になりません。古いCNAMEが残っていると、リクエストがinblogに向かい続けてしまいます。
• デフォルトのinblogドメイン（xxx.inblog.io）と以前のカスタムドメインでは、リダイレクトの動作が異なります。サブドメインおよびルートドメインの接続では、ドメインが認証され、ブログに対象となるTeam以上のプランまたは有効なトライアルがある場合、デフォルトドメインは自動的にリダイレクトされます。サブディレクトリ接続の場合、デフォルトドメインのリダイレクトはプロキシの設定によって異なります。デフォルトドメインをオリジンとして使用しているプロキシの場合、そのアドレスが送り返されるとループが発生する可能性があります。このリダイレクトに頼る前に、チャットでお問い合わせいただき設定をご確認ください。正規URLは、優先URLとしてサブディレクトリのアドレスを別途指定します。以前のカスタムドメインからのリダイレクトは、引き続きお客様のチーム側で設定する必要があります。

移行中にブログはダウンしますか？

新しいプロキシ設定を確認した後、新しいサブディレクトリのアドレスでブログが読み込まれることを確認してください。また、デフォルトドメインのリダイレクト動作と以前のカスタムドメインのリダイレクトルールも個別に確認してください。既存のWebサイト側は、/blog パスのルールを追加する以外に変更される部分はありません。

変更されたアドレスを検索エンジンが再インデックスするまでには時間がかかります。古い各アドレスから対応する新しいページへの恒久的なリダイレクトを設定してください。新しいルールには308を推奨しますが、正常に機能している既存の301を変更する必要はありません。リダイレクトは新しいアドレスを通知するものであり、インデックス登録、順位、トラフィックを保証するものではありません。

ドメイン変更後、投稿内のリンクやCTAボタンも自動的に更新されますか？

いいえ — 投稿内に直接記述されたアドレスはそのまま残ります。 正規URL、サイトマップ、RSS、カテゴリー／著者ページは新しいドメインに合わせて再生成されますが、以下の2つは投稿自体に保存されているため自動的には追従しません:

• 本文内の絶対アドレス（https://old-domain/... を指すリンク、画像、ボタンなど）
• 各投稿の下部にあるCTAボタンのURL
• 投稿にご自身で手動入力した正規URL（canonical URL）。 投稿ごとに設定された正規URLは自動生成されるものより優先されるため、古いドメインを指し続けます。

下部CTAは一括で変更できます。 投稿管理で投稿を選択し、編集をクリックして一括編集ダイアログを開きます。そこでCTA設定をオンにし、CTAリンクに新しいアドレスを入力すると、選択したすべての投稿に一度に適用されます。

• 一括編集は、選択した投稿を同じ値で上書きします。投稿ごとに「古いドメイン → 新しいドメイン」を個別に置換する機能はないため、リンク先が異なる場合は同じアドレスを持つ投稿ごとにグループ化して、バッチ単位で適用してください。
• 本文内のリンクは一括編集の対象外です。 投稿を開いて個別に編集してください。
• 古いアドレスに恒久的なリダイレクトを設定していれば訪問者は新しいアドレスへ転送されますが、投稿内に保存されているリンク自体は古いドメインを指したままとなります。

各投稿のCTAリンクが異なり、ドメイン部分のみを置き換えたい場合

何百もの投稿があり、CTAリンクがそれぞれ異なるため一括編集の「すべて同じ値にする」方法が使えない場合は、Posts APIを使用してドメイン部分のみを置き換えることができます。専用の機能の追加を待つ必要はありません。

1. 左側メニューの設定 → APIキーで、posts:read および posts:write スコープを含むAPIキーを発行します。

2. page[number] と page[size] を指定して GET /api/v1/posts をページごとに呼び出し、各投稿の cta_link を取得します。

3. 値に古いドメインが含まれている投稿のみを抽出します。

4. パス、クエリ、ハッシュはそのまま残し、ドメインのみを新しいものに置き換えます。

5. 各投稿に対して、cta_link フィールドのみを含めた PATCH /api/v1/posts/{POST_ID} を送信します。リクエストボディは次のようになります:

   { "data": { "type": "posts", "attributes": { "cta_link": "https://new-domain/path" } } }
   

6. 投稿を再度取得し、古いドメインが残っていないことを確認します。

cta_link のみを送信する場合、本文、タイトル、公開状態は変更されません。ただし、各投稿の updated_at は更新されるため、処理したすべての投稿についてサイトマップ内の lastmod の値がその日付に変わる点にご注意ください。全件に対して実行する前に、まず少数の投稿で試して結果を確認することをお勧めします。正確なリクエスト形式については、APIドキュメントを参照してください。

ご自身でスクリプトを実行することが難しい場合は、ブログのアドレスを添えてチャットでお問い合わせください。

ドメインをお持ちでない場合も問題ありません

カスタムドメインをお持ちでない場合は、設定時に「I don't own a domain」オプションを選択することで、デフォルトのブログドメイン（例: example.inblog.io）を引き続き使用できます。カスタムドメインへのアップグレードはいつでも可能です。

メインのWebサイトのナビゲーションに「ブログ」タブを追加するにはどうすればよいですか？

inblogはメインWebサイトのナビゲーションメニューを制御しません。ブログへのリンクを追加するには、メインサイトの構築に使用したツール（Webflow、Framer、WordPress、お使いのCMSなど）でナビゲーションを更新してください。

リンク先としてinblogのブログアドレスを使用します:

• サブドメイン: https://blog.example.com
• サブディレクトリ: https://example.com/blog

カスタムドメインを接続する前であれば、デフォルトのinblogドメイン（例: https://example.inblog.io）を一時的に使用することもできます。

ブログヘッダーのロゴをクリックしたときにメインのWebサイトに戻るようにするにはどうすればよいですか？

inblogダッシュボードで、デザインタブ → ヘッダーに移動します。そこでロゴ画像と、訪問者がロゴをクリックしたときに遷移するURLを設定できます。メインWebサイトのURLを入力すると、訪問者をホームページにリダイレクトできます。

最終更新 2026-10-14