Подключение собственного домена

Подключите блог на inblog с помощью поддомена (например, blog.example.com), корневого домена или подкаталога (например, example.com/blog), следуя инструкциям по настройке DNS.

Обзор

Раздел настройки домена может потребовать помощи разработчика, особенно при настройке DNS или реализации кода. При необходимости доступны сессии технической поддержки.

Вы можете подключить блог inblog одним из трех способов:

• Поддомен (например, blog.example.com)
• Корневой домен (например, example.com)
• Подкаталог (например, example.com/blog)

Где добавлять DNS-записи: DNS-настройки необходимо добавлять там, где домен управляется (например, Namecheap, GoDaddy, Cloudflare), а не там, где создан ваш сайт (например, Webflow, Framer). Если ваш сайт создан на Webflow, но домен приобретен на GoDaddy, добавляйте DNS-записи в GoDaddy.

Где найти настройки домена

1. Войдите в систему на inblog.ai/dashboard. Вы попадете на список ваших блогов.
2. Нажмите на карточку блога, который хотите настроить. Домены настраиваются отдельно для каждого блога, поэтому, если вы ведете несколько блогов, убедитесь, что выбран нужный блог.
3. В левом меню в группе Настройки нажмите Домен. (Не нужно открывать экран Настройки и искать внутри — нажмите Домен прямо в левом меню.)
4. В верхней части экрана «Домен» выберите вкладку Подкаталог, Поддомен или Корневой домен, введите свой адрес и нажмите Начать подключение. На вкладке «Подкаталог» затем выберите используемую веб-инфраструктуру, после чего появится пошаговое руководство по настройке обратного прокси.

Если экран «Домен» неактивен (выделен серым) и не принимает ввод, блог находится на бесплатном тарифе (Free Plan). Собственные домены доступны на тарифе Team Plan, включая 14-дневный бесплатный пробный период.

Если при нажатии на карточку открывается экран начальной настройки вместо экрана управления, выполните шаг настройки домена там. Подробнее см. в разделе начальной настройки в статье Начало работы с inblog.

Настройка поддомена

В настройках собственного домена выберите «Поддомен» и введите свой домен — без поддоменной части. Поле уже содержит фиксированный префикс https://blog., поэтому ввод example.com здесь всегда подключает blog.example.com.

Блог может использовать только один метод подключения одновременно, поэтому вы не можете запускать 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 или добавить второй домен?

Нет. Для одного блога предусмотрен ровно один собственный домен. При подключении поддомена и корневого домена inblog выпускает SSL-сертификат только для зарегистрированного адреса. Он не может принимать и перенаправлять запросы для адреса, который не зарегистрирован, и отдельного поля для псевдонима (alias) www также нет.

Если вам требуется перенаправление www.example.com → example.com (например, потому что Google уже считает версию с www канонической):

• Направление www на inblog только через CNAME вызовет ошибку сертификата, такую как ERR_CERT_COMMON_NAME_INVALID — www является отдельным именем хоста, и сертификата для него нет.

• Оставьте в inblog зарегистрированным только ваш канонический адрес, а www направьте на сервис перенаправления того, кто управляет вашим доменом или хостингом (Cloudflare, Vercel, ваш веб-сервер). Выпустите сертификат для www там, затем добавьте постоянное перенаправление, как показано ниже. Мы рекомендуем 308 для новых правил; сохраняйте корректно работающий 301 или используйте 301, если ваш провайдер поддерживает только его. См. раздел 308 vs 301 and when to use each:

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

• Сохраняйте путь и строку запроса (query string) в правиле. Обратное направление (example.com → www.example.com) настраивается аналогично.

Если вы хотите использовать два адреса одновременно (например, сохранить blog.example.com и добавить example.com/guide):

• Создайте второй блог и подключите второй адрес к нему.
• В inblog и подписки, и подключения доменов действуют для каждого блога отдельно, поэтому одна подписка Team Plan не может покрывать два блога. Для нового блога требуется отдельная подписка — см. 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 для хоста в собственной учетной записи Cloudflare, а существующий сайт работает при статусе DNS-записи Proxied. Наличия Cloudflare в заголовках ответа или при проверке IP-адреса недостаточно для соответствия этому требованию.
• Framer / Webflow: поддерживаются через обратный прокси с использованием Cloudflare

Перед использованием руководства по Cloudflare: продолжайте только в том случае, если существующий сайт уже работает в режиме Proxied, а целевой путь (например, /blog) не используется либо его существующий контент и URL-адреса уже перенесены. Запись DNS only, SaaS-конструкторы сайтов, другие CDN или прокси, а также учетные записи без возможности управления Cloudflare Zone и Worker Routes требуют отдельного рассмотрения. Если хост не может оставаться проксируемым, используйте вместо этого подключение поддомена.

Руководство по подключению в панели также предоставляет пошаговую настройку для AWS CloudFront и Nginx.

Если вашего окружения нет в этом списке (например, Apache), выберите Другое / Связаться с нами. Любой веб-сервер, способный проксировать определенный путь на внешний origin, может быть подключен через собственный обратный прокси — свяжитесь с нами в чате, и мы проверим возможность подключения вместе с вами.

Выберите «Подкаталог» в настройках собственного домена и введите свой домен (например, example.com/blog). Нажмите Начать подключение, чтобы открыть полное руководство по настройке. Обратите внимание, что настройка подкаталога обычно требует реализации кода.

Выбор веб-инфраструктуры ничего не меняет на стороне inblog. Он лишь определяет, какое руководство по настройке вы увидите, поэтому его изменение позже никак не повлияет на уже подключенный домен.

Если перед вашим веб-сервером (Apache, Nginx и т. д.) уже установлен CDN или прокси, такой как Cloudflare или CloudFront, выбирайте этот CDN, независимо от сервера-источника. Обработка правила проксирования в месте первичного поступления запросов проще и не затрагивает конфигурацию вашего origin-сервера.

Моего регистратора домена нет в списке «веб-инфраструктуры»

Так и должно быть. В списке запрашивается, откуда в настоящее время обслуживается ваш сайт, а не где вы купили домен. На экране указано: «Выберите инфраструктуру, на которой размещен ваш веб-сайт, и следуйте соответствующему руководству ниже». В нем перечислены только те среды, для которых inblog предоставляет готовое руководство по проксированию, поэтому регистраторы и DNS-провайдеры, такие как Namecheap или GoDaddy, здесь не представлены.

Если ваш провайдер предоставляет как домены, так и веб-хостинг (Gabia, Cafe24 и подобные), ориентируйтесь на веб-сервер, на котором фактически работает ваш сайт — обычно это Apache или Nginx, — а не на название провайдера. Nginx означает Nginx; Apache или любая система, которую вы не можете точно определить, означает Другое / Связаться с нами.

Список содержит: NextJS, Vercel, AWS Amplify, AWS CloudFront, Cloudflare, Nginx, Webflow, Framer и Другое / Связаться с нами. (В корейском интерфейсе панели также отображаются Cafe24 и Imweb; при выборе любого из них выводится сообщение, что подключение подкаталога недоступно для этой среды.)

Как определиться с выбором:

1. Если перед вашим сайтом установлен CDN или прокси, такой как Cloudflare или AWS CloudFront, выбирайте этот CDN независимо от сервера-источника.
2. В противном случае выберите сервер или платформу, которая фактически обслуживает сайт (Nginx, Vercel, NextJS, Framer и т. д.).
3. Если сайт создан с помощью инструмента, которого нет в списке (WordPress, PHP), ориентируйтесь на сервер, на котором он работает, а не на инструмент разработки. WordPress на Nginx — это Nginx; WordPress на Apache в списке отсутствует, поэтому выберите Другое / Связаться с нами.
4. Если вы не уверены, выберите Другое / Связаться с нами — откроется чат с нами, и мы вместе проверим возможность подключения.

Если сайт создавало агентство, уточните у них два момента

1. Какой веб-сервер или хостинг обслуживает сайт в настоящее время (Nginx, Apache, Vercel и т. д.), и установлен ли перед ним CDN, например Cloudflare или CloudFront.
2. Могут ли они добавить правило обратного прокси (rewrite) только для /blog и /blog/*. Это должен быть именно rewrite, а не редирект.

Нужно ли выбирать веб-инфраструктуру для поддомена?

Нет. Выбор веб-инфраструктуры появляется только при подключении подкаталога.

Подключение поддомена (blog.example.com) и корневого домена (example.com) никак не затрагивает сервер вашего существующего сайта — вы лишь добавляете DNS-записи, — поэтому данный экран вообще не появляется. Если вы видите список инфраструктур, значит, вы сейчас проходите процесс подключения подкаталога.

Если вы не можете добавить правило проксирования на сервере своего сайта, переключение на подключение поддомена на вкладке «Домен» обычно является более быстрым решением: для него требуются только DNS-записи у того, кто управляет вашим доменом.

Настройка подкаталога через AWS CloudFront

Чтобы настроить inblog в подкаталоге с использованием AWS CloudFront, ознакомьтесь со следующими шагами настройки.

1. Используйте дистрибуцию, которая обслуживает ваш основной сайт, или создайте новую дистрибуцию, если CloudFront еще не настроен.
2. Установите Distribution name в inblog proxy, а Domain в example.com.
3. Установите Origin type в Другие, Custom origin в proxy.inblog.dev, а Origin path в /{subdomain}.
4. Установите origin request policy в Managed-AllViewerExceptHostHeader, чтобы CloudFront не пересылал заголовок Host посетителя на proxy.inblog.dev.
5. Создайте CloudFront Function для перезаписи URI и вставьте следующий код.

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. Добавьте behaviors для /blog, /blog/* и /robots.txt.
7. Опубликуйте функцию в Live, затем прикрепите ее к событию Viewer request для всех трех behaviors.

После развертывания проверьте следующие URL-адреса из терминала.

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

CloudFront возвращает ошибку 502

Сначала убедитесь, что вы не оставили Origin path пустым. Для подключения подкаталога используется Custom origin proxy.inblog.dev вместе с Origin path /{subdomain}, а не отдельное значение CNAME.

Если ваши настройки совпадают с этим требованием, но ошибки 502 сохраняются, проверьте следующие пункты по порядку. В большинстве случаев причина кроется в одном из них.

1. Все три behavior — /blog, /blog/* и /robots.txt — используют origin proxy.inblog.dev.
2. Все три behavior используют политику origin request policy Managed-AllViewerExceptHostHeader. Если пересылается заголовок Host посетителя, origin не сможет обработать запрос.
3. CloudFront Function опубликована в Live — простого сохранения недостаточно.
4. Эта функция прикреплена к событию Viewer request во всех трех behaviors.
5. Дистрибуция завершила развертывание (Deployed), включая ваши последние изменения.

Если все вышеперечисленное проверено, но ошибка 502 сохраняется, отправьте нам вывод трех приведенных ниже команд. Сравнение запроса через CloudFront с запросом напрямую к origin позволяет нам локализовать причину.

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} вашими собственными значениями.

Сначала определите, к какому серверу относятся правила. Компания, у которой вы купили домен (регистратор/nameservers), зачастую не является машиной, которая фактически обслуживает ваш сайт. Если ваши nameservers находятся у хостинг-провайдера, а сам сайт работает на Apache на инстансе AWS EC2, правила проксирования вносятся в конфигурацию Apache этого инстанса EC2, а не в панель DNS хостинг-провайдера.

Добавьте следующие строки в VirtualHost, обслуживающий ваш сайт (VirtualHost для порта 443, если используется HTTPS).

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-адресов конкретных статей не требуется.
• Две строки RequestHeader внутри <Location "/blog"> сообщают inblog адрес, который фактически открывают посетители (example.com), и подкаталог, в котором он обслуживается (/blog). Прокси удаляет их, а аналитике они нужны для правильной атрибуции URL-адресов статей. Маршрутизация их не считывает, поэтому блог продолжит работать, даже если их пропустить (для них требуется модуль mod_headers). Обязательно держите их внутри блока <Location>: на уровне всего VirtualHost они добавлялись бы к каждому запросу на вашем собственном сайте и могли бы нарушить формирование URL-адресов в вашем приложении.
• ProxyPreserveHost Off — критически важная строка. Если заголовок Host посетителя передается без изменений, inblog не сможет обработать запрос. Эта директива выполняет ту же роль, что и политика Managed-AllViewerExceptHostHeader в CloudFront или proxy_set_header Host proxy.inblog.dev в Nginx.
• Пропустите правила для /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

Если у вас нет прав (sudo) на редактирование файла VirtualHost, обратитесь к администратору сервера с просьбой применить конфигурацию выше.

Мой блог в подкаталоге возвращает ERR_TOO_MANY_REDIRECTS

Путь блога застрял в циклическом перенаправлении и совсем не загружается. Причиной обычно является правило для /blog на вашем собственном сайте. Вот две самые частые причины.

1. Это должен быть rewrite, а не redirect

Передача пути /blog в inblog требует перезаписи (обратного проксирования, rewrite) — адрес в строке браузера остается прежним, а ваш сервер возвращает ответ от inblog. При использовании redirect запрос к /blog перенаправляет обратно на /blog, что приводит к бесконечному циклу.

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

2. Форма с www отличается в inblog и в каноническом адресе вашего сайта

Если ваш сайт использует example.com (без www) в качестве канонического, но адрес, зарегистрированный в inblog, указан как www.example.com/blog, редиректы с www и без www будут конфликтовать между собой. Выберите единый формат.

• Зарегистрируйте адрес на вкладке «Домен» в inblog в том же виде, который ваш сайт использует в качестве канонического.
• Настройте склейку www → без 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}

Если вторая команда возвращает 200, с inblog все в порядке, и вам нужно лишь восстановить правило /blog на своем сайте. Если вторая команда также завершается ошибкой, отправьте нам вывод в чат.

3. Вспомните, что менялось в последнее время

• Повторное развертывание (redeploy) сайта — если конфигурация прокси не входит в файлы сборки, каждое развертывание стирает правило.
• Изменения правил CDN или WAF, либо добавление новой политики защиты от ботов.
• Замена конфигурации веб-сервера, продление сертификатов или аналогичные технические работы на сервере.

4. Проверьте предупреждение в панели управления

Если в разделе Настройки → Домен отображается предупреждение, в следующем разделе объясняется значение каждого сообщения.

Что означает предупреждение о проверке подключения на карточке домена?

inblog периодически проверяет, действительно ли ваш подключенный домен обслуживает этот блог, и выводит Предупреждение о проверке подключения домена в разделе Настройки → Домен, если не получает ожидаемого ответа.

Само по себе предупреждение не блокирует доступ посетителей к блогу и исчезает автоматически, как только очередная проверка завершится успешно. Каждое сообщение указывает на определенную проблему.

Перезапишет ли настройка подкаталога мой существующий robots.txt?

Руководство по настройке включает правило, которое проксирует /robots.txt на inblog наряду с путями блога (/blog, /blog/*). Это правило предназначено для сайтов, у которых еще нет robots.txt. Если вы уже ведете собственный файл, не применяйте его в исходном виде.

У домена может быть только один robots.txt: он отдается из корня и применяется ко всем путям ниже него. Проксирование /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. Сохраните проксирование и редактируйте robots.txt внутри inblog

• Перейдите в Настройки → SEO Tools → Robots.txt в панели управления (на платном тарифе после подключения собственного домена).
• Вставьте туда ваши существующие правила и сохраните строку с картой сайта блога. Все сохраненные данные будут отдаваться в качестве ответа по адресу example.com/robots.txt.
• Редактор изначально заполнен значениями по умолчанию, сформированными inblog (разрешить всем краулерам, плюс URL-адреса sitemap). Очистите его полностью и сохраните, чтобы вернуться к значениям по умолчанию.

Вам не нужно поддерживать карту сайта вручную. При настроенном прокси файл example.com/blog/sitemap.xml автоматически генерируется inblog каждый раз, когда вы публикуете или редактируете статью. Загружать или обновлять xml-файл со своей стороны не требуется.

Подкаталог и Google Search Console

Когда вы подключаете подкаталог (например, example.com/blog), трафик вашего блога включается в существующий ресурс корневого домена в Search Console. Если вы хотите анализировать данные только по блогу отдельно, вы можете добавить дополнительный ресурс с типом Только адрес этого блога:

• Тип ресурса: URL prefix
• URL: https://example.com/blog

Для этого отдельного ресурса также требуется подтверждение с помощью собственного HTML-тега. Добавьте мета-тег для этого ресурса в панели управления inblog на вкладке Design → Advanced settings (Code injection).

Кнопка «Начать подключение» не срабатывает, или всплывает ошибка

Это этап до добавления DNS-записей — само подключение не может начаться.

Если запрос отклонен, экран «Домен» покажет ошибку рядом с полем ввода адреса или во всплывающем окне. Ознакомьтесь с возможными причинами ниже перед повторной попыткой.

Проверьте следующее по порядку:

1. Убедитесь, что вы находитесь на платном тарифе. Подключение собственного домена доступно только на платных тарифах, поэтому на бесплатном тарифе запросы на подключение отклоняются.
2. Убедитесь, что вашей учетной записи разрешено подключать домены. Только владелец (owner), администратор (admin) или редактор (editor) этого блога — с уже принятым приглашением — может подключать или отключать домен.
3. Не подключайте и не отключайте домен многократно за короткий промежуток времени. Запросы на подключение/отключение домена ограничены лимитом 10 операций в час. При превышении этого лимита все последующие попытки отклоняются и процесс не продвигается. Настройки не сбились — просто подождите около часа и попробуйте один раз.
4. Проверьте формат ввода. На вкладке «Поддомен» поле уже содержит префикс https://blog., поэтому вводите только example.com — без https:// или www. На вкладке «Подкаталог» требуется полный путь, например 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; подключение поддомена и корневого домена выполняется путем добавления DNS-записей, предоставленных inblog, поэтому наличие существующего сайта не требуется.

Что означает (не подтверждено) в списке блогов?

После добавления DNS-записей статус домена в списке блогов в панели управления inblog может отображаться как (не подтверждено). Это означает, что inblog еще не подтвердил ваши DNS-записи. Распространенные причины:

• DNS-записи еще не добавлены или их значения указаны неверно.
• Распространение изменений DNS занимает до 24–48 часов после внесения изменений.

Как только статус изменится на (подтверждено), проверка DNS завершена. Для полного открытия доступа к домену может потребоваться еще несколько минут.

На вкладке «Домен» отображается «Выпуск SSL-сертификата». Стоит ли просто подождать?

В большинстве случаев — да. Если только на домене не настроена запись CAA, с вашей стороны больше ничего делать не требуется. Статус «Выпуск SSL-сертификата» появляется только после того, как ваши DNS-записи были подтверждены, когда настройка HTTPS остается последним незавершенным шагом. Это означает, что ваши записи уже успешно прошли проверку.

При подключении поддомена и корневого домена на вкладке «Домен» отображается одно из четырех состояний подключения:

Для подключения подкаталога отображается другой набор из трех состояний: Требуется настройка обратного прокси, Проверка подключения обратного прокси и Подключено.

Распространение DNS-изменений может занимать от 24 до 48 часов, а сайту может потребоваться еще несколько минут, чтобы начать открываться после выпуска сертификата.

• Если для домена настроена запись CAA, проверьте и ее — она может блокировать выпуск сертификата.
• Если статус «Выпуск SSL-сертификата» не меняется более суток, отправьте нам подключаемый адрес и скриншот.

На карточке домена написано «Не удалось найти серверы имен для этого домена»

inblog проверяет серверы имен (nameservers) корневого домена, стоящего за введенным вами адресом (например, blog.example.com → example.com), чтобы подсказать, в какой DNS-сервис нужно добавлять записи. Это предупреждение означает, что проверка ничего не вернула. Проверьте следующее:

• Домен написан без ошибок.
• Домен действительно зарегистрирован и срок его действия не истек.
• У вашего регистратора домена назначены серверы имен (сразу после покупки поле может быть пустым).

Это предупреждение относится только к проверке, с помощью которой мы подсказываем вам, какой DNS-сервис использовать, и не блокирует саму верификацию. Если у домена действительно не назначены серверы имен, добавленные записи также не будут резолвиться, поэтому сначала завершите настройку nameservers у вашего регистратора. Если после добавления записей подключение продолжается в штатном режиме, это предупреждение можно проигнорировать.

У меня все работает, но другие не могут открыть мой блог

Иногда статус домена показывает «Подтверждено» и блог отлично загружается у вас, но люди, которым вы отправляете ссылку, не могут на него зайти. Обычно это не является ошибкой настройки домена — в сети, которой они пользуются (домашний Wi-Fi, мобильный оператор, корпоративная сеть), в кэше DNS все еще сохраняется старое состояние. Изменения DNS распространяются с разной скоростью в разных сетях в течение 24–48 часов, поэтому публичные DNS уже могут отдавать правильные данные, тогда как некоторые сети все еще не резолвят адрес.

Что делать:

• Делитесь полным адресом (например, https://blog.example.com), а не его частью.
• Попросите тех, у кого сайт не открывается, переключиться на мобильный интернет вместо Wi-Fi или повторить попытку чуть позже.
• Если спустя 24–48 часов сайт по-прежнему не открывается в конкретной сети, пришлите нам точный используемый адрес и скриншот ошибки из этого окружения.

Можно ли перенести блог с поддомена в подкаталог?

Да. Переключите тип подключения на Подкаталог на вкладке «Домен» и зарегистрируйте новый адрес (например, example.com/blog). Обратите внимание, что блог использует один тип подключения одновременно, поэтому blog.example.com и example.com/blog не могут работать параллельно.

Что обновится автоматически

• Слаги (slugs) статей не изменятся. Меняются только хост и начальный путь, поэтому редактировать каждую статью по отдельности не придется.
• Канонические URL-адреса, карта сайта, RSS и адреса страниц категорий/авторов переключатся на новый адрес сразу после подтверждения нового подключения (кэшу может потребоваться несколько минут для обновления).
• Автоматизации по API и CLI (Make, Zapier, n8n и т. д.) не пострадают. Ключ API привязан к самому блогу, а не к собственному домену, поэтому смена типа подключения не нарушит их работу.

Что вам потребуется настроить самостоятельно

• Самостоятельно настройте постоянное перенаправление (рекомендуется 308) со старого пользовательского поддомена (blog.example.com). После его отключения inblog больше не отвечает на этом хосте, поэтому добавьте правило blog.example.com/{slug} → example.com/blog/{slug} там, где вы управляете доменом или хостингом. Поскольку слаги остаются прежними, достаточно одного правила, меняющего хост и добавляющего префикс /blog.
• Сначала перенаправьте DNS-запись blog.example.com в сторону от inblog, иначе правило редиректа не сработает: пока сохраняется старая запись CNAME, запросы продолжат поступать в inblog.
• Стандартный домен inblog (xxx.inblog.io) и ваш старый пользовательский домен имеют разное поведение перенаправления. Для подключений поддомена и корневого домена стандартный домен перенаправляет трафик автоматически, когда домен подтвержден, а блог находится на подходящем тарифе Team (или выше) либо на активном пробном периоде. Для подключений подкаталога перенаправления со стандартного домена зависят от конфигурации прокси: если прокси использует стандартный домен в качестве origin, может возникнуть циклический редирект. Свяжитесь с нами в чате, чтобы проверить вашу настройку, прежде чем полагаться на этот редирект. Канонический URL отдельно указывает поисковым системам на адрес подкаталога как на предпочтительный. Настройка редиректов со старого пользовательского домена в любом случае остается за вашей командой.

Будет ли блог недоступен во время переключения?

После проверки настроек нового прокси убедитесь, что блог загружается по новому адресу подкаталога. Также отдельно проверьте поведение редиректа со стандартного домена и правила редиректа со старого пользовательского домена. Ваш существующий сайт не затрагивается, за исключением добавления правила для пути /blog.

Поисковым системам требуется время на переиндексацию измененного адреса. Настройте постоянный редирект с каждого старого адреса на соответствующую новую страницу. Мы рекомендуем 308 для новых правил, однако менять существующий корректно работающий 301 не требуется. Редиректы сообщают поисковикам о новом адресе, но не гарантируют мгновенную индексацию, сохранение позиций или трафика.

Обновляются ли ссылки и кнопки CTA внутри моих статей после смены домена?

Нет — адреса, прописанные внутри текста статьи, остаются без изменений. Канонические URL, карта сайта, RSS и страницы категорий/авторов перегенерируются для нового домена, однако следующие два элемента хранятся в самой статье и автоматически не обновляются:

• Абсолютные адреса в тексте (ссылки, изображения или кнопки, указывающие на https://old-domain/...)
• URL-адрес на нижней CTA-кнопке каждой статьи
• Канонический URL, который вы ввели в настройках статьи вручную. Индивидуальный канонический URL имеет приоритет над сгенерированным, поэтому он продолжит указывать на старый домен.

Нижние CTA можно изменить массово. В разделе Управление записями выберите нужные статьи и нажмите Изменить, чтобы открыть окно массового редактирования. Затем включите Настройки CTA и введите новый адрес в поле Ссылка CTA, чтобы применить его ко всем выбранным материалам одновременно.

• Массовое редактирование перезаписывает выбранные статьи одним и тем же значением. Инструмента поиска и замены «старый домен → новый домен» для отдельных статей нет, поэтому, если ссылки различаются, сгруппируйте статьи с одинаковыми адресами и примените изменения пакетами.
• Ссылки в тексте статей не затрагиваются массовым редактированием. Откройте статью и отредактируйте их вручную.
• Постоянный редирект со старого адреса перенаправит посетителей на новый адрес, но ссылки, сохраненные внутри ваших статей, продолжат указывать на старый домен.

Что делать, если у каждой статьи разная ссылка CTA и нужно заменить только домен

Если у вас сотни статей и у каждой из них уникальная CTA-ссылка (поэтому массовое редактирование с одинаковым значением не подходит), вы можете заменить только домен через Posts API. Ждать появления специальной функции не требуется.

1. В левом меню в разделе Настройки → API-ключи выпустите API-ключ с правами posts:read и posts:write.

2. Вызовите метод GET /api/v1/posts постранично, используя параметры page[number] и page[size], чтобы прочитать поле cta_link каждой статьи.

3. Отфильтруйте только те статьи, значение которых содержит старый домен.

4. Оставьте путь, параметры запроса и хэш неизменными, заменив только домен на новый.

5. Для каждой статьи отправьте запрос PATCH /api/v1/posts/{POST_ID}, передав только поле cta_link. Тело запроса выглядит следующим образом:

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

6. Запросите статьи повторно и убедитесь, что старого домена не осталось.

Отправка только поля cta_link оставляет тело статьи, заголовок и статус публикации без изменений. Обратите внимание, что это обновляет значение updated_at статьи, поэтому значения lastmod в вашей карте сайта изменятся на текущую дату для каждого обработанного материала. Мы рекомендуем сначала протестировать это на нескольких статьях и проверить результат перед обработкой всего массива. Точный формат запроса см. в API docs.

Если вы не можете выполнить это самостоятельно, напишите нам в чат, указав адрес вашего блога.

Нет домена? Не проблема.

Если у вас нет собственного домена, продолжайте использовать стандартный домен блога (например, example.inblog.io), выбрав при настройке вариант «У меня нет домена». Вы можете перейти на собственный домен в любое удобное время.

Как добавить вкладку «Блог» в навигацию моего основного сайта?

inblog не управляет меню навигации вашего основного сайта. Чтобы добавить ссылку на блог, обновите навигацию в инструменте, на котором создан ваш основной сайт (например, Webflow, Framer, WordPress или ваша CMS).

Используйте адрес вашего блога на inblog в качестве целевой ссылки:

• Поддомен: https://blog.example.com
• Подкаталог: https://example.com/blog

До подключения собственного домена вы можете временно использовать стандартный домен inblog, например https://example.inblog.io.

Как сделать так, чтобы логотип в шапке блога вел на мой основной сайт?

В панели управления inblog перейдите на вкладку Design → Header. Там вы можете настроить изображение логотипа и URL-адрес, на который переходят посетители при нажатии на него. Укажите URL вашего основного сайта, чтобы перенаправлять посетителей на главную страницу.

Последнее обновление 2026-10-14