Conectando um domínio personalizado

Conecte seu blog do inblog usando um subdomínio (ex.: blog.example.com), domínio raiz ou subdiretório (ex.: example.com/blog), com orientações sobre configuração de DNS.

Visão geral

A seção de configuração de domínio pode exigir a ajuda de um desenvolvedor, especialmente para a configuração de DNS ou implementação de código. Sessões de suporte técnico estão disponíveis se necessário.

Você pode conectar seu blog do inblog usando uma destas três abordagens:

• Subdomínio (ex.: blog.example.com)
• Domínio raiz (ex.: example.com)
• Subdiretório (ex.: example.com/blog)

Onde adicionar os registros DNS: as configurações de DNS devem ser adicionadas onde seu domínio é gerenciado (ex.: Namecheap, GoDaddy, Cloudflare), não onde seu site foi construído (ex.: Webflow, Framer). Se você criou seu site no Webflow, mas comprou o domínio pelo GoDaddy, adicione os registros DNS no GoDaddy.

Onde encontrar as configurações de domínio

1. Faça login em inblog.ai/dashboard. Você entrará na sua lista de blogs.
2. Clique no card do blog que deseja configurar. Os domínios são configurados por blog; portanto, se você gerencia mais de um, verifique se o blog correto está selecionado.
3. No menu à esquerda, abaixo do título do grupo Configurações, clique em Domínio. (Você não precisa abrir a tela Configurações e procurar lá dentro — clique em Domínio diretamente no menu à esquerda).
4. Na parte superior da tela Domínio, escolha a aba Subdiretório, Subdomínio ou Domínio raiz, informe seu endereço e clique em Iniciar conexão. Na aba Subdiretório, selecione a infraestrutura web que você utiliza para ver o guia passo a passo do proxy reverso correspondente.

Se a tela Domínio estiver esmaecida e não aceitar entradas, o blog está no Plano Gratuito. Os domínios personalizados estão disponíveis no Plano Team, incluindo o período de teste gratuito de 14 dias.

Se clicar no card abrir uma tela de configuração inicial em vez da tela de gerenciamento, siga a etapa de domínio apresentada nela. Consulte a seção de configuração inicial em Primeiros passos com o inblog para obter detalhes.

Configuração de subdomínio

Nas configurações de Domínio personalizado, selecione Subdomínio e informe seu domínio — sem a parte do subdomínio. O campo possui o prefixo fixo https://blog., portanto, digitar example.com aqui sempre conectará blog.example.com.

Um blog usa apenas um método de conexão por vez; por isso, você não pode operar blog.example.com e news.example.com simultaneamente no mesmo blog.

Clique em Iniciar conexão para receber as instruções de configuração do DNS. Adicione os registros no seu provedor de DNS exatamente como exibidos. As alterações de DNS podem levar até 24 horas para propagar, e o inblog verifica a conexão automaticamente.

Se outra pessoa gerencia seu domínio, use Copiar mensagem de solicitação abaixo dos registros DNS e envie a mensagem para seu desenvolvedor ou administrador do domínio. Ela inclui o endereço e todos os registros necessários.

Se o seu provedor de DNS rejeitar o valor CNAME: alguns provedores (ex.: Gabia) exigem que o valor seja um nome de domínio totalmente qualificado e exibem um erro como "o valor deve terminar com um ponto (.)". Nesse caso, adicione um ponto final ao valor exato fornecido pelo inblog. Por exemplo, se o inblog mostrar abc123.vercel-dns-016.com, digite abc123.vercel-dns-016.com.. Outros provedores (ex.: Imweb) esperam o valor sem o ponto final. Siga o formato solicitado pelo seu provedor.

Também posso conectar www ou adicionar um segundo domínio?

Não. Um blog comporta exatamente um domínio personalizado. Para conexões de subdomínio e domínio raiz, o inblog emite um certificado SSL apenas para o endereço que você registrou. Ele não pode receber e redirecionar solicitações para um endereço que não esteja registrado, e também não há um campo de alias separado para www.

Se você precisa de www.example.com → example.com (por exemplo, porque o Google já trata a versão com www como canônica):

• Apontar o www para o inblog usando apenas um CNAME gera um erro de certificado como ERR_CERT_COMMON_NAME_INVALID — www é um hostname separado e não existe nenhum certificado para ele.

• Deixe apenas o seu endereço canônico registrado no inblog e aponte o www para o serviço de redirecionamento de quem gerencia seu domínio ou hospedagem (Cloudflare, Vercel, seu servidor web). Emita um certificado para www lá e adicione um redirecionamento permanente conforme abaixo. Recomendamos o 308 para novas regras; mantenha um 301 que já funcione corretamente ou use 301 se o seu provedor suportar apenas este. Consulte 308 vs 301 e quando usar cada um:

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

• Preserve o caminho e a query string na regra. A direção inversa (example.com → www.example.com) funciona da mesma forma.

Se você deseja manter dois endereços funcionando ao mesmo tempo (por exemplo, manter blog.example.com e adicionar example.com/guide):

• Crie um segundo blog e conecte o segundo endereço a ele.
• Tanto as assinaturas quanto as conexões de domínio são por blog no inblog; logo, uma única assinatura do Plano Team não cobre dois blogs. O novo blog precisará de sua própria assinatura — consulte as Perguntas frequentes (FAQ).
• Se já existir uma página no caminho que você deseja adicionar (digamos que example.com/guide atualmente abre outro conteúdo), conectá-lo como subdiretório substituirá esse caminho pelo inblog. Mova a página existente para outro local ou escolha um caminho que esteja livre.

Configuração de subdiretório (subpasta)

O painel atualmente oferece guias de configuração para Next.js, Vercel, AWS Amplify, AWS CloudFront, Cloudflare, Nginx, Webflow e Framer. Escolha Outro / Fale conosco se a sua infraestrutura não estiver listada.

As plataformas suportadas incluem:

• Next.js: Suportado, exceto para exportação estática
• Vercel / AWS Amplify: Suportados como plataformas de hospedagem
• Cloudflare: Suportado quando você puder gerenciar a Zone, o Worker e as Routes do hostname na sua própria conta da Cloudflare, e o site existente funcionar enquanto seu registro DNS estiver em Proxied. Apenas ver a Cloudflare nos cabeçalhos de resposta ou na consulta de IP não atende a esse requisito.
• Framer / Webflow: Suportados via proxy reverso usando Cloudflare

Antes de usar o guia da Cloudflare: continue apenas quando o site existente já funcionar como Proxied e o caminho de destino (por exemplo, /blog) não estiver em uso ou seus conteúdos e URLs atuais já tiverem sido migrados. Um registro em DNS only, um criador de sites SaaS, outro CDN ou proxy, ou uma conta sem permissão para gerenciar Cloudflare Zone e Worker Routes exigem análise prévia. Se o hostname não puder permanecer como proxied, use uma conexão por subdomínio.

O guia de conexão do painel também oferece a configuração passo a passo para AWS CloudFront e Nginx.

Se o seu ambiente não estiver nessa lista (Apache, por exemplo), escolha Outro / Fale conosco. Qualquer servidor web capaz de encaminhar um caminho específico para uma origem externa via proxy pode ser conectado por meio de um proxy reverso personalizado — fale conosco pelo chat para confirmarmos a viabilidade com você.

Selecione Subdiretório nas configurações de Domínio personalizado e informe seu domínio (ex.: example.com/blog). Clique em Iniciar conexão para acessar o guia completo de configuração. Tenha em mente que a configuração de subdiretório geralmente exige implementação de código.

A seleção de "infraestrutura web" não altera nada do lado do inblog. Ela serve apenas para definir qual guia de configuração você verá; portanto, alterá-la mais tarde não afeta um domínio que você já conectou.

Se um CDN ou proxy como Cloudflare ou CloudFront já estiver à frente do seu servidor web (Apache, Nginx, etc.), selecione esse CDN, independentemente do servidor de origem. Gerenciar a regra de proxy onde as solicitações chegam primeiro é mais simples e mantém a configuração da sua origem intacta.

O registrador do meu domínio não está na lista de "infraestrutura web"

Isso é esperado. A lista pergunta de onde o seu site é servido atualmente, não onde você comprou o domínio. A tela informa: "Escolha a infraestrutura onde o seu site está hospedado e siga o guia correspondente abaixo". Ela lista apenas os ambientes para os quais o inblog fornece um guia de proxy; registradores e provedores de DNS como Namecheap ou GoDaddy não são opções aqui.

Se o seu provedor vende tanto domínios quanto hospedagem de sites (Gabia, Cafe24 e similares), baseie-se no servidor web no qual o seu site realmente roda — geralmente Apache ou Nginx — em vez do nome do provedor. Nginx significa Nginx; Apache, ou qualquer um que você não consiga confirmar, significa Outro / Fale conosco.

A lista contém: NextJS, Vercel, AWS Amplify, AWS CloudFront, Cloudflare, Nginx, Webflow, Framer e Outro / Fale conosco. (O painel em coreano também exibe Cafe24 e Imweb; selecionar qualquer um deles informa que a conexão por subdiretório não está disponível para esse ambiente).

Como decidir:

1. Se um CDN ou proxy como Cloudflare ou AWS CloudFront estiver à frente do seu site, escolha esse CDN independentemente do servidor de origem.
2. Caso contrário, selecione o servidor ou plataforma que realmente serve o site (Nginx, Vercel, NextJS, Framer, etc.).
3. Se o site foi construído com algo que não está listado (WordPress, PHP), baseie-se no servidor em que ele roda, não na ferramenta com que foi criado. WordPress no Nginx é Nginx; WordPress no Apache não está listado, portanto escolha Outro / Fale conosco.
4. Se você não souber identificar, selecione Outro / Fale conosco — isso abrirá um chat conosco e confirmaremos a viabilidade juntos.

Se uma agência desenvolveu o seu site, pergunte duas coisas a ela

1. Qual servidor web ou hospedagem serve o site hoje (Nginx, Apache, Vercel, etc.) e se há um CDN como Cloudflare ou CloudFront à frente dele.
2. Se eles podem adicionar uma regra de proxy reverso (rewrite) apenas para /blog e /blog/*. Deve ser uma reescrita (rewrite), não um redirecionamento (redirect).

Preciso escolher uma infraestrutura web para um subdomínio?

Não. A seleção de infraestrutura web só é exibida para conexões por subdiretório.

Conexões por subdomínio (blog.example.com) e domínio raiz (example.com) nunca mexem no servidor do seu site existente — você apenas adiciona registros DNS — por isso a tela nem sequer aparece. Se você está vendo a lista de infraestruturas, está no fluxo de subdiretório.

Se você não puder adicionar uma regra de proxy no servidor do seu site, mudar para uma conexão por subdomínio na aba Domínio geralmente é o caminho mais rápido: requer apenas registros DNS em quem gerencia o seu domínio.

Configuração de subdiretório com AWS CloudFront

Para configurar o inblog em um subdiretório usando o AWS CloudFront, siga as etapas de configuração abaixo.

1. Use a distribution que serve seu site principal ou crie uma nova distribution se o CloudFront ainda não estiver configurado.
2. Defina Distribution name como inblog proxy e Domain como example.com.
3. Defina Origin type como Other, Custom origin como proxy.inblog.dev e Origin path como /{subdomain}.
4. Defina a origin request policy como Managed-AllViewerExceptHostHeader para que o CloudFront não encaminhe o cabeçalho Host do visitante para proxy.inblog.dev.
5. Crie uma CloudFront Function para reescrita de URI e cole o código a seguir.

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. Adicione behaviors para /blog, /blog/* e /robots.txt.
7. Publique a function em Live e vincule-a ao evento Viewer request nos três behaviors.

Após o deploy, verifique as seguintes URLs no seu terminal.

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

O CloudFront retorna um erro 502

Primeiro, certifique-se de que você não deixou o Origin path vazio. Uma conexão por subdiretório usa Custom origin proxy.inblog.dev junto com Origin path /{subdomain} — e não um valor CNAME separado.

Se as suas configurações estiverem corretas e os erros 502 persistirem, verifique os seguintes itens em ordem. Na maioria dos casos, um deles foi esquecido.

1. Todos os três behaviors — /blog, /blog/* e /robots.txt — usam a origem proxy.inblog.dev.
2. Todos os três behaviors usam a origin request policy Managed-AllViewerExceptHostHeader. Se o cabeçalho Host do visitante for encaminhado, a origem não conseguirá atender à solicitação.
3. A CloudFront Function está publicada em Live — apenas salvá-la não é suficiente.
4. Essa function está associada ao evento Viewer request em todos os três behaviors.
5. A distribution concluiu a implantação (Deployed), incluindo a sua alteração mais recente.

Se tudo acima estiver correto e o 502 continuar, envie-nos o retorno dos três comandos abaixo. Comparar uma solicitação pelo CloudFront com uma solicitação direta à origem nos permite isolar a causa.

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

Configuração de subdiretório com Apache

O Apache não está na lista de infraestruturas do painel, portanto escolha Outro / Fale conosco e adicione as regras de proxy reverso você mesmo no Apache. Substitua example.com, /blog e {subdomain} pelos seus próprios valores.

Primeiro, confirme em qual servidor as regras devem ser adicionadas. A empresa onde você comprou o domínio (registrador/nameservers) muitas vezes não é a máquina que realmente hospeda seu site. Se seus nameservers estão em um provedor de hospedagem, mas o site em si roda no Apache em uma instância AWS EC2, as regras de proxy devem entrar na configuração do Apache dessa instância EC2, e não na tela de DNS do provedor de hospedagem.

Adicione o seguinte ao VirtualHost que serve o seu site (o VirtualHost da porta 443 se você usa 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" também encaminha tudo o que estiver abaixo de /blog, dispensando regras separadas para URLs de posts individuais.
• As duas linhas RequestHeader dentro de <Location "/blog"> informam ao inblog o endereço que os visitantes realmente acessam (example.com) e o subdiretório sob o qual ele é servido (/blog). O proxy remove ambos, e as ferramentas de analytics precisam deles para atribuir URLs de posts corretamente. O roteamento nunca lê esses cabeçalhos; portanto, o blog continuará funcionando se você omiti-los (eles exigem mod_headers). Mantenha-os dentro do bloco <Location>: no escopo do VirtualHost, eles seriam anexados a todas as requisições do seu próprio site e poderiam alterar a forma como sua aplicação constrói URLs.
• ProxyPreserveHost Off é a linha crítica. Se o cabeçalho Host do visitante for encaminhado sem alteração, o inblog não conseguirá atender à requisição. Ele cumpre o mesmo papel da política Managed-AllViewerExceptHostHeader do CloudFront e de proxy_set_header Host proxy.inblog.dev no Nginx.
• Pule as regras de /robots.txt se você já tiver seu próprio robots.txt. Veja A configuração de subdiretório sobrescreverá meu robots.txt existente? abaixo.

Habilite os módulos necessários, teste a configuração e recarregue.

Ubuntu / Debian

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

Amazon Linux / CentOS / RHEL (os módulos geralmente já estão ativados)

sudo apachectl configtest
sudo systemctl reload httpd

Assim que ambas as URLs abaixo retornarem 200, o status na tela Domínio do inblog mudará automaticamente para Conectado.

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

Se você não tiver permissão (sudo) para editar o arquivo do VirtualHost, peça para o responsável pela administração do servidor aplicar a configuração acima.

Meu blog em subdiretório retorna ERR_TOO_MANY_REDIRECTS

O caminho do blog está preso em um loop de redirecionamento e não carrega. A causa costuma ser uma regra de /blog no seu próprio site. Estas duas são as mais comuns.

1. Deve ser um rewrite, não um redirect

Passar /blog para o inblog requer uma reescrita (proxy reverso) — o endereço permanece o mesmo e seu servidor responde com a resposta do inblog. Um redirect faz a requisição de /blog apontar novamente para /blog, criando um loop infinito.

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

2. O formato com www difere entre o inblog e o endereço canônico do seu site

Se o seu site trata example.com (sem www) como canônico, mas o endereço registrado no inblog for www.example.com/blog, os redirecionamentos de www e sem www entrarão em conflito. Defina um único formato padrão.

• Registre o endereço na aba Domínio do inblog no mesmo formato que seu site utiliza como canônico.
• Aplique a consolidação www → sem www nas configurações de redirecionamento de domínio do seu host, em uma única direção — e não como uma regra específica de /blog.

Como identificar qual lado está com problema

Compare os cabeçalhos de resposta para cada endereço. Se o último comando retornar 200, normalmente são as regras de redirecionamento do seu site que precisam de correção — veja a ressalva logo abaixo para exceções. Se retornar um código 3xx, o lado do inblog precisa ser verificado — envie-nos esse resultado pelo chat.

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

Se a regra já for um rewrite, proxy.inblog.dev responder com 200, mas o loop persistir, verifique o cabeçalho location na resposta do primeiro comando. Quando ele envia você de volta para o endereço que acabou de solicitar, nenhuma alteração adicional do seu lado resolverá. Pare de editar as regras e nos envie esse cabeçalho de resposta completo pelo chat.

Um Aviso na verificação da conexão do domínio no card de domínio pode ter a mesma causa. Ele também aparece em bloqueios de firewall ou falhas temporárias, e desaparece sozinho na próxima verificação assim que as regras de proxy funcionarem. Consulte O que significa o aviso de verificação de conexão para entender cada mensagem detalhadamente.

Meu blog funcionava ontem e agora retorna 404

Nada mudou no inblog, mas todo o endereço example.com/blog retorna 404. A causa mais comum é que um novo deploy, alteração de CDN ou mudança de firewall no seu site removeu ou sobrescreveu a regra de proxy de /blog.

Primeiro: não desconecte o domínio no inblog. Remover e readicionar a conexão não restaurará a regra de proxy do seu site — apenas forçará você a passar pela verificação do domínio novamente.

1. Identifique qual página 404 você está vendo

O aspecto visual da página 404 indica até onde a solicitação chegou.

2. Isole o lado com falha usando uma requisição

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

Se o segundo comando retornar 200, o inblog está funcionando normalmente e você só precisa restaurar a regra de /blog no seu site. Se o segundo comando também falhar, envie-nos essa saída pelo chat.

3. Relembre o que mudou recentemente

• Um novo deploy do site — se a configuração do proxy não fizer parte dos arquivos de build, cada deploy apagará a regra.
• Alterações em regras de CDN ou WAF, ou uma política recém-adicionada de proteção contra bots.
• Substituição de configurações do servidor web, renovação de certificado ou manutenção similar no servidor.

4. Verifique também o aviso no painel

Se Configurações → Domínio exibir um aviso, a seção abaixo explica o significado de cada mensagem.

O que significa o 'Aviso na verificação da conexão do domínio' no card de domínio?

O inblog verifica periodicamente se o seu domínio conectado realmente serve este blog e exibe um Aviso na verificação da conexão do domínio em Configurações → Domínio quando não recebe a resposta esperada.

O aviso por si só não impede os visitantes de acessarem o seu blog e desaparece automaticamente assim que uma verificação posterior for bem-sucedida. Cada mensagem indica um ponto diferente.

A configuração de subdiretório sobrescreverá meu robots.txt existente?

O guia de configuração inclui uma regra que faz o proxy de /robots.txt para o inblog junto com os caminhos do seu blog (/blog, /blog/*). Essa regra existe para sites que ainda não possuem um robots.txt. Se você já mantém o seu próprio arquivo, não aplique a regra como está.

Um domínio tem apenas um robots.txt, servido a partir da raiz e aplicado a todos os caminhos abaixo dele. Fazer o proxy de /robots.txt significa que o arquivo do inblog responderá em vez do seu, anulando as regras de Disallow que você já tinha.

Se você já possui um robots.txt, escolha uma destas opções:

1. Remova apenas a regra de /robots.txt (recomendado)

• Mantenha as regras de proxy para os caminhos do seu blog (/blog, /blog/*) e remova apenas a regra de /robots.txt.
• Adicione o sitemap do seu blog ao robots.txt existente:

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

• Confirme que nenhuma das suas regras de Disallow existentes bloqueia o caminho do blog (/blog).

2. Mantenha o proxy e edite o robots.txt dentro do inblog

• Vá para Configurações → Ferramentas de SEO → Robots.txt no painel (plano pago, após a conexão do domínio personalizado).
• Cole suas regras existentes lá e mantenha a linha do sitemap do blog. Tudo o que você salvar será servido como resposta para example.com/robots.txt.
• O editor vem pré-preenchido com o padrão que o inblog gera (permitir todos os crawlers, além das URLs do sitemap). Limpe-o totalmente e salve para retornar a esse padrão.

Você não precisa manter o sitemap manualmente. Com o proxy configurado, example.com/blog/sitemap.xml é regenerado pelo inblog sempre que você publica ou edita um post. Não há nenhum arquivo xml para enviar ou atualizar do seu lado.

Subdiretório e Google Search Console

Quando você conecta um subdiretório (ex.: example.com/blog), o tráfego do seu blog é incluído na propriedade existente do Search Console do domínio raiz. Se você quiser analisar os dados apenas do blog separadamente, pode adicionar uma propriedade adicional de Somente este endereço do blog:

• Tipo de propriedade: Prefixo do URL
• URL: https://example.com/blog

Essa propriedade separada também exige sua própria verificação por tag HTML. Adicione a meta tag para essa propriedade no painel do inblog na aba Design → Configurações avançadas (Injeção de código).

"Iniciar conexão" não faz nada ou um popup de erro bloqueia a próxima etapa

Esta é a etapa que ocorre antes dos registros DNS — a conexão em si não inicia.

Se a solicitação for rejeitada, a tela Domínio exibirá um erro perto do campo de endereço ou em um popup. Verifique as causas abaixo antes de tentar novamente.

Verifique os itens a seguir em ordem.

1. Confirme se você está em um plano pago. Conectar um domínio personalizado é um recurso de plano pago; logo, as solicitações de conexão são rejeitadas no plano gratuito.
2. Confirme se a sua conta tem permissão para conectar domínios. Apenas um proprietário, administrador ou editor desse blog — com o convite já aceito — pode conectar ou desconectar um domínio.
3. Não conecte e desconecte repetidamente em um curto período. As solicitações de conexão/desconexão de domínio são limitadas a 10 por hora. Ultrapassado esse limite, todas as tentativas seguintes serão rejeitadas e não avançarão. Nada está desconfigurado — basta aguardar cerca de uma hora e tentar uma vez novamente.
4. Verifique o formato da entrada. A aba Subdomínio já prefixa o campo com https://blog., portanto digite apenas example.com — sem https:// ou www. A aba Subdiretório espera o caminho completo, como www.example.com/blog.
5. (Subdiretório) Confirme se o domínio digitado já resolve publicamente na internet. Antes de iniciar a conexão, o inblog consulta a parte do domínio de www.example.com/blog (www.example.com) no DNS público. Se esse host exato não tiver registro público A, AAAA ou CNAME, a consulta falhará e a solicitação será rejeitada. (Se você digitou www, o registro precisará existir no host com www).

Uma conexão por subdiretório integra seu blog a um site que já está no ar. Esta etapa apenas verifica se o registro DNS existe, mas os passos seguintes exigirão que você adicione uma regra de proxy reverso nesse site. Adicione primeiro o registro DNS apontando para o seu site existente, confirme que https://www.example.com abre normalmente e só então inicie a conexão. Na Cloudflare, esse registro deve estar como Proxied.

Se este for um domínio novo que ainda não possui nenhum site ativo, a conexão por subdiretório não é a opção adequada — não há nenhum site onde aplicar uma regra de proxy. Em vez disso, use um subdomínio como blog.example.com; as conexões de subdomínio e domínio raiz funcionam adicionando os registros DNS que o inblog fornece, sem exigir um site pré-existente.

O que significa (não verificado) na lista de blogs?

Depois de adicionar os registros DNS, o status do domínio na lista de blogs do painel do inblog pode aparecer como (não verificado). Isso significa que o inblog ainda não confirmou seus registros DNS. Motivos comuns:

• Os registros DNS ainda não foram adicionados ou os valores estão incorretos.
• A propagação do DNS leva de 24 a 48 horas após as alterações serem feitas.

Assim que o status mudar para (verificado), a confirmação do DNS estará concluída. O domínio pode levar mais alguns minutos para ficar totalmente acessível.

A aba Domínio diz "Emitindo certificado SSL". Devo apenas esperar?

Na maioria dos casos, sim. A menos que você tenha configurado um registro CAA no domínio, não há mais nada a fazer. "Emitindo certificado SSL" aparece apenas depois que seus registros DNS foram confirmados, quando a configuração de HTTPS for a última etapa pendente. Isso significa que seus registros já passaram na validação.

Para conexões de subdomínio e domínio raiz, a aba Domínio exibe um de quatro estados de conexão:

Conexões por subdiretório exibem um conjunto diferente de três estados: Configuração de proxy reverso necessária, Verificando a conexão de proxy reverso e Conectado.

As alterações de DNS podem levar de 24 a 48 horas para se propagarem, e o site pode levar mais alguns minutos para abrir após a emissão do certificado.

• Se você tiver definido um registro CAA no domínio, verifique-o também — ele pode bloquear a emissão do certificado.
• Se o status continuar em "Emitindo certificado SSL" por mais de um dia, envie-nos o endereço que você está conectando acompanhado de uma captura de tela.

O card do domínio diz "Could not find nameservers for this domain."

O inblog consulta os nameservers do domínio raiz associado ao endereço digitado (ex.: blog.example.com → example.com) para indicar em qual serviço de DNS você deve adicionar os registros. Esse aviso significa que a consulta não retornou nenhum resultado. Verifique o seguinte:

• Se o domínio foi digitado corretamente.
• Se o domínio está realmente registrado e não expirou.
• Se os nameservers estão atribuídos no seu registrador de domínio (eles podem estar vazios logo após a compra).

Este aviso reflete apenas a verificação usada para indicar qual serviço de DNS você deve usar — ele não bloqueia a verificação. Se o domínio genuinamente não tiver nameservers atribuídos, os registros adicionados também não resolverão; portanto, conclua primeiro a configuração de nameservers no seu registrador. Se a conexão prosseguir normalmente após a inclusão dos registros, você poderá ignorar este aviso.

Funciona para mim, mas outras pessoas não conseguem abrir meu blog

Às vezes, o status do domínio exibe "Verificado" e o blog carrega perfeitamente para você, mas as pessoas com quem você compartilha o link não conseguem acessá-lo. Geralmente, isso não é um problema na configuração do domínio — a rede em que elas estão (Wi-Fi residencial, operadora móvel, rede corporativa) ainda mantém o estado antigo no cache DNS. As alterações de DNS propagam-se em velocidades diferentes em redes diferentes por até 24 a 48 horas; logo, o DNS público já pode estar correto enquanto algumas redes ainda não conseguem resolver o endereço.

O que fazer:

• Compartilhe o endereço completo (ex.: https://blog.example.com) em vez de um endereço parcial.
• Peça a quem não conseguir acessar para testar pelos dados móveis em vez do Wi-Fi, ou para tentar novamente um pouco mais tarde.
• Se o problema persistir em uma rede específica após 24 a 48 horas, envie-nos o endereço exato utilizado e uma captura de tela do erro obtido nesse ambiente.

Posso mudar um blog em subdomínio para um subdiretório?

Sim. Altere o tipo de conexão para Subdiretório na aba Domínio e registre o novo endereço (ex.: example.com/blog). Lembre-se de que um blog usa um tipo de conexão por vez; por isso, blog.example.com e example.com/blog não podem rodar simultaneamente.

O que acontece automaticamente

• Os slugs dos posts não mudam. Apenas o host e o caminho inicial mudam, eliminando qualquer retrabalho post por post.
• URLs canônicas, o sitemap, RSS e endereços de páginas de categoria/autor mudam para o novo endereço assim que a nova conexão for verificada (os caches podem levar alguns minutos para atualizar).
• Automações de API e CLI (Make, Zapier, n8n, etc.) não são afetadas. Uma chave de API está vinculada ao blog em si e não ao domínio personalizado, portanto alterar o tipo de conexão não a invalida.

O que você precisa gerenciar por conta própria

• Configure você mesmo um redirecionamento permanente (308 recomendado) do seu antigo subdomínio personalizado (blog.example.com). Após desconectá-lo, o inblog não responderá mais nesse host; configure uma regra de blog.example.com/{slug} → example.com/blog/{slug} onde você gerencia o domínio ou hospedagem. Como os slugs permanecem inalterados, uma única regra que troque o host e adicione o prefixo /blog é suficiente.
• Aponte primeiro o registro DNS de blog.example.com para fora do inblog, caso contrário a regra de redirecionamento não terá efeito — com o CNAME antigo mantido, as solicitações continuarão sendo enviadas para o inblog.
• O domínio padrão do inblog (xxx.inblog.io) e o seu antigo domínio personalizado possuem comportamentos de redirecionamento distintos. Para conexões de subdomínio e domínio raiz, o domínio padrão redireciona automaticamente quando o domínio é verificado e o blog está em um plano Team ou superior qualificado ou em período de teste ativo. Para conexões por subdiretório, os redirecionamentos do domínio padrão dependem da configuração do proxy: um proxy que usa o domínio padrão como sua origem pode entrar em loop se esse endereço redirecionar de volta. Fale conosco pelo chat para checar sua configuração antes de depender desse redirecionamento. A URL canônica indica separadamente o endereço do subdiretório como a URL preferencial. Sua equipe ainda deve configurar os redirecionamentos a partir do antigo domínio personalizado.

O blog sairá do ar durante a transição?

Após verificar a nova configuração do proxy, teste se o blog carrega no novo endereço de subdiretório. Verifique também o comportamento de redirecionamento do domínio padrão e as regras de redirecionamento do antigo domínio personalizado separadamente. O seu site atual não será afetado além da adição da regra para o caminho /blog.

Os mecanismos de busca precisam de tempo para indexar um endereço modificado. Configure um redirecionamento permanente de cada endereço antigo para sua página correspondente nova. Recomendamos o código 308 para novas regras, mas não é necessário alterar um 301 existente que já esteja funcionando perfeitamente. Redirecionamentos sinalizam o novo endereço, mas não garantem indexação, posicionamento ou tráfego.

Após uma mudança de domínio, os links e botões de CTA dentro dos meus posts também são atualizados?

Não — endereços inseridos diretamente no corpo de um post permanecem como estão. URLs canônicas, sitemap, RSS e páginas de categoria/autor são regenerados com base no novo domínio, mas estes dois itens ficam salvos no próprio post e não se atualizam sozinhos:

• Endereços absolutos no corpo do texto (links, imagens ou botões apontando para https://old-domain/...)
• A URL configurada no botão de CTA inferior de cada post
• Uma URL canônica que você tenha digitado manualmente no post. Um canônico definido individualmente no post tem prioridade sobre o gerado automaticamente, continuando a apontar para o domínio antigo.

Os CTAs inferiores podem ser alterados em massa. No Gerenciador de posts, selecione os posts e clique em Editar para abrir a janela de edição em massa, depois ative Configurações do CTA e insira o novo endereço em Link do CTA para aplicá-lo a todos os posts selecionados de uma só vez.

• A edição em massa sobrescreve os posts selecionados com o mesmo valor. Não existe um recurso de localizar e substituir que troque "domínio antigo → domínio novo" por post; logo, se os links forem diferentes, agrupe os posts que compartilham o mesmo endereço e aplique as alterações em lotes.
• Links no corpo do texto não são contemplados pela edição em massa. Abra o post e edite-os individualmente.
• Um redirecionamento permanente no endereço antigo encaminhará os visitantes para o novo, mas os links salvos nos seus posts continuarão apontando para o domínio antigo.

Quando cada post tem um link de CTA diferente e você só quer substituir o domínio

Se você tiver centenas de posts cujos links de CTA são todos diferentes — de modo que a aplicação do "mesmo valor em todos" pela edição em massa não sirva —, você pode substituir apenas o domínio usando a API de Posts. Não é preciso esperar por um recurso específico na interface.

1. No menu à esquerda, em Configurações → Chaves de API, gere uma chave de API com os escopos posts:read e posts:write.

2. Chame GET /api/v1/posts página por página utilizando page[number] e page[size] para ler o cta_link de cada post.

3. Filtre apenas os posts cujo valor contenha o domínio antigo.

4. Mantenha o caminho, a query e a hash inalterados e substitua apenas o domínio pelo novo.

5. Para cada post, envie PATCH /api/v1/posts/{POST_ID} contendo apenas o campo cta_link. O corpo da requisição deve ser assim:

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

6. Consulte os posts novamente para confirmar que nenhum resquício do domínio antigo permaneceu.

Enviar apenas o cta_link mantém o corpo, o título e o estado de publicação intactos. Observe que isso atualiza o updated_at de cada post, fazendo com que os valores de lastmod no sitemap passem para essa nova data em todos os posts processados. Recomendamos testar em alguns posts primeiro e conferir o resultado antes de executar em lote completo. Veja a documentação da API para checar o formato exato das requisições.

Se você não tiver familiaridade técnica para rodar esse processo, entre em contato pelo nosso chat informando o endereço do seu blog.

Não tem um domínio? Sem problemas.

Se você não tiver um domínio personalizado, continue usando o domínio padrão do blog (ex.: example.inblog.io) selecionando a opção "Não tenho um domínio" durante a configuração. Você pode migrar para um domínio personalizado a qualquer momento.

Como adiciono uma aba "Blog" na navegação do meu site principal?

O inblog não gerencia o menu de navegação do seu site principal. Para adicionar um link para o blog, atualize o menu de navegação na ferramenta usada para construir seu site principal (ex.: Webflow, Framer, WordPress ou seu CMS próprio).

Use o endereço do seu blog no inblog como link de destino:

• Subdomínio: https://blog.example.com
• Subdiretório: https://example.com/blog

Antes de conectar um domínio personalizado, você pode usar temporariamente o domínio padrão do inblog, ex.: https://example.inblog.io.

Como faço para o logo no cabeçalho do blog levar de volta ao meu site principal?

No painel do inblog, acesse a aba Design → Cabeçalho. Nela você pode configurar a imagem do logo e a URL para onde os visitantes serão direcionados ao clicar sobre ele. Digite a URL do seu site principal para redirecionar os visitantes para sua página inicial.

Última atualização em 2026-10-14