Conectar un dominio personalizado

Conecta tu blog creado con inblog mediante un subdominio (p. ej., blog.example.com), un dominio raíz o un subdirectorio (p. ej., example.com/blog), con instrucciones sobre la configuración de DNS.

Resumen

La sección de configuración del dominio puede requerir la ayuda de un desarrollador, en particular para la configuración de DNS o la implementación de código. Hay sesiones de soporte técnico disponibles si es necesario.

Puedes conectar tu blog creado con inblog mediante uno de estos tres enfoques:

• Subdominio (p. ej., blog.example.com)
• Dominio raíz (p. ej., example.com)
• Subdirectorio (p. ej., example.com/blog)

Dónde añadir los registros DNS: La configuración de DNS debe añadirse donde se gestiona tu dominio (p. ej., Namecheap, GoDaddy, Cloudflare), no donde se crea tu sitio web (p. ej., Webflow, Framer). Si creaste tu sitio en Webflow pero compraste el dominio a través de GoDaddy, añade los registros DNS en GoDaddy.

Dónde encontrar la configuración del dominio

1. Inicia sesión en inblog.ai/dashboard. Llegarás a tu lista de blogs.
2. Haz clic en la tarjeta del blog que quieras configurar. Los dominios se configuran por blog, por lo que si gestionas más de uno, comprueba que esté seleccionado el blog correcto.
3. En el menú de la izquierda, debajo del encabezado del grupo Configuración, haz clic en Dominio. (No abras la pantalla de Configuración para buscarlo dentro; haz clic directamente en Dominio en el menú izquierdo).
4. En la parte superior de la pantalla Dominio, selecciona la pestaña Subdirectorio, Subdominio o Dominio raíz, introduce tu dirección y haz clic en Iniciar conexión. En la pestaña Subdirectorio, elige la infraestructura web que utilizas y aparecerá la guía de proxy inverso correspondiente paso a paso.

Si la pantalla Dominio aparece en gris y no permite introducir datos, el blog se encuentra en el plan gratuito. Los dominios personalizados están disponibles en el Plan Team, incluida la prueba gratuita de 14 días.

Si al hacer clic en la tarjeta se abre una pantalla de configuración inicial en lugar de la pantalla de administración, sigue el paso del dominio allí. Consulta la sección de configuración inicial en Primeros pasos con inblog para obtener más detalles.

Configuración de subdominio

En la configuración de Dominio personalizado, selecciona Subdominio e introduce tu dominio, sin la parte del subdominio. El campo tiene el prefijo fijo https://blog., por lo que introducir example.com aquí siempre conectará blog.example.com.

Un blog utiliza un solo método de conexión a la vez, por lo que no puedes utilizar blog.example.com y news.example.com de forma simultánea.

Haz clic en Iniciar conexión para recibir las instrucciones de configuración de DNS. Añade los registros en tu proveedor de DNS exactamente como se muestran. Los cambios de DNS pueden tardar hasta 24 horas en propagarse, e inblog comprueba la conexión automáticamente.

Si otra persona gestiona tu dominio, utiliza Copiar mensaje de solicitud debajo de los registros DNS y envíale el mensaje a tu desarrollador o administrador de dominio. Incluye la dirección y cada registro que deben añadir.

Si tu proveedor de DNS rechaza el valor CNAME: algunos proveedores (p. ej., Gabia) requieren que el valor sea un nombre de dominio completo (FQDN) y muestran un error como "el valor debe terminar con un punto (.)". En ese caso, añade un punto al final del valor exacto que te proporcionó inblog. Por ejemplo, si inblog muestra abc123.vercel-dns-016.com, introduce abc123.vercel-dns-016.com.. Otros proveedores (p. ej., Imweb) esperan el valor sin el punto final. Sigue el formato que solicite tu proveedor.

¿Puedo conectar también www o añadir un segundo dominio?

No. Un blog tiene exactamente un dominio personalizado. Para las conexiones de subdominio y dominio raíz, inblog emite un certificado SSL únicamente para la dirección que registraste. No puede recibir ni redirigir solicitudes para una dirección que no esté registrada, y tampoco existe un campo de alias independiente para www.

Si necesitas www.example.com → example.com (por ejemplo, porque Google ya trata la versión con www como canónica):

• Apuntar www a inblog solo con un CNAME produce un error de certificado como ERR_CERT_COMMON_NAME_INVALID; www es un hostname independiente y no existe ningún certificado para él.

• Deja únicamente tu dirección canónica registrada en inblog y apunta www al servicio de redirección de quien gestione tu dominio o hosting (Cloudflare, Vercel, tu servidor web). Emite un certificado para www allí y luego añade una redirección permanente como se indica a continuación. Recomendamos 308 para reglas nuevas; mantén un 301 que funcione correctamente o usa 301 si tu proveedor solo admite ese tipo. Consulta 308 frente a 301 y cuándo usar cada uno:

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

• Conserva la ruta y la cadena de consulta (query string) en la regla. La dirección inversa (example.com → www.example.com) funciona de la misma manera.

Si deseas utilizar dos direcciones a la vez (por ejemplo, mantener blog.example.com y añadir example.com/guide):

• Crea un segundo blog y conéctale la segunda dirección.
• Tanto las suscripciones como las conexiones de dominio son por blog en inblog, por lo que una suscripción al Plan Team no puede cubrir dos blogs. El nuevo blog necesita su propia suscripción; consulta las Preguntas frecuentes (FAQ).
• Si ya existe una página en la ruta que deseas añadir (por ejemplo, si example.com/guide abre actualmente otro contenido), conectarla como subdirectorio reemplazará esa ruta con inblog. Mueve la página existente a otro lugar o elige una ruta que esté libre.

Configuración de subdirectorio (subcarpeta)

El panel de control proporciona actualmente guías de configuración para Next.js, Vercel, AWS Amplify, AWS CloudFront, Cloudflare, Nginx, Webflow y Framer. Elige Otro / Contacto si tu infraestructura no aparece en la lista.

Las plataformas compatibles incluyen:

• Next.js: compatible, excepto para la exportación estática
• Vercel / AWS Amplify: compatibles como plataformas de hosting
• Cloudflare: compatible cuando puedes gestionar la Zona, el Worker y las Rutas del hostname en tu propia cuenta de Cloudflare, y el sitio web existente funciona mientras su registro DNS está en modo Proxied. Que aparezca Cloudflare en los encabezados de respuesta o en una búsqueda de IP por sí solo no cumple con este requisito.
• Framer / Webflow: compatibles mediante proxy inverso utilizando Cloudflare

Antes de utilizar la guía de Cloudflare: continúa solo si el sitio web existente ya funciona mientras está en modo Proxied, y la ruta de destino (por ejemplo, /blog) no está en uso o su contenido y URL existentes han sido migrados. Un registro en DNS only, un creador de sitios web SaaS, otra CDN o proxy, o una cuenta que no pueda gestionar la Zona de Cloudflare y las Worker Routes requieren una revisión aparte. Si el hostname no puede permanecer con proxy, utiliza una conexión por subdominio en su lugar.

La guía de conexión del panel también proporciona una configuración paso a paso para AWS CloudFront y Nginx.

Si tu entorno no está en esa lista (Apache, por ejemplo), elige Otro / Contacto. Cualquier servidor web que pueda redirigir por proxy una ruta específica hacia un origen externo se puede conectar a través de un proxy inverso personalizado; comunícate por el chat y confirmaremos la viabilidad contigo.

Selecciona Subdirectorio en la configuración de Dominio personalizado e introduce tu dominio (p. ej., example.com/blog). Haz clic en Iniciar conexión para ver la guía de configuración completa. Ten en cuenta que la configuración de subdirectorio normalmente requiere implementación de código.

El selector de "infraestructura web" no cambia nada en el lado de inblog. Solo determina qué guía de configuración ves, por lo que cambiarlo más adelante no afecta a un dominio que ya hayas conectado.

Si una CDN o proxy como Cloudflare o CloudFront ya se encuentra delante de tu servidor web (Apache, Nginx, etc.), selecciona esa CDN independientemente del servidor de origen. Gestionar la regla de proxy donde llegan primero las solicitudes es más sencillo y deja intacta la configuración de tu origen.

Mi registrador de dominios no está en la lista de "infraestructura web"

Es normal. La lista pregunta desde dónde se sirve tu sitio web actualmente, no dónde compraste el dominio. La pantalla indica: "Elige la infraestructura donde está alojado tu sitio web y luego sigue la guía correspondiente a continuación". Solo enumera los entornos para los que inblog incluye una guía de proxy, por lo que los registradores y proveedores de DNS como Namecheap o GoDaddy no son opciones aquí.

Si tu proveedor vende tanto dominios como alojamiento web (Gabia, Cafe24 y similares), guíate por el servidor web en el que realmente se ejecuta tu sitio (generalmente Apache o Nginx) en lugar del nombre del proveedor. Nginx significa Nginx; Apache, o cualquier entorno que no puedas confirmar, significa Otro / Contacto.

La lista contiene: NextJS, Vercel, AWS Amplify, AWS CloudFront, Cloudflare, Nginx, Webflow, Framer y Otro / Contacto. (Un panel en idioma coreano también muestra Cafe24 e Imweb; al seleccionar cualquiera de los dos, se informa que la conexión por subdirectorio no está disponible para ese entorno).

Cómo decidir:

1. Si una CDN o proxy como Cloudflare o AWS CloudFront está delante de tu sitio, elige esa CDN independientemente del servidor de origen.
2. De lo contrario, elige el servidor o plataforma que realmente sirve el sitio (Nginx, Vercel, NextJS, Framer, etc.).
3. Si el sitio se creó con algo que no está en la lista (WordPress, PHP), guíate por el servidor en el que se ejecuta, no por la herramienta con la que se creó. WordPress en Nginx es Nginx; WordPress en Apache no aparece en la lista, por lo que debes elegir Otro / Contacto.
4. Si no puedes saberlo, elige Otro / Contacto: abrirá un chat con nosotros y confirmaremos la viabilidad juntos.

Si una agencia creó tu sitio, pregúntales dos cosas

1. Qué servidor web o hosting sirve el sitio actualmente (Nginx, Apache, Vercel, etc.) y si hay una CDN como Cloudflare o CloudFront delante de él.
2. Si pueden añadir una regla de proxy inverso (reescritura o rewrite) únicamente para /blog y /blog/*. Debe ser una reescritura, no una redirección.

¿Necesito elegir una infraestructura web para un subdominio?

No. El selector de infraestructura web solo aparece para las conexiones de subdirectorio.

Las conexiones por subdominio (blog.example.com) y por dominio raíz (example.com) nunca tocan el servidor de tu sitio web existente (solo añades registros DNS), por lo que la pantalla no aparece en absoluto. Si estás viendo la lista de infraestructura, estás en el flujo de subdirectorio.

Si no puedes añadir una regla de proxy en el servidor de tu sitio web, cambiar a una conexión por subdominio en la pestaña Dominio suele ser el camino más rápido: solo requiere registros DNS en la entidad que gestiona tu dominio.

Configuración de subdirectorio con AWS CloudFront

Para configurar inblog en un subdirectorio mediante AWS CloudFront, revisa los siguientes pasos de configuración.

1. Usa la distribución que sirve tu sitio web principal o crea una nueva distribución si CloudFront aún no está configurado.
2. Establece Distribution name en inblog proxy y Domain en example.com.
3. Establece Origin type en Otros, Custom origin en proxy.inblog.dev y Origin path en /{subdomain}.
4. Establece la directiva de solicitud de origen (origin request policy) en Managed-AllViewerExceptHostHeader para que CloudFront no reenvíe el encabezado Host del visor a proxy.inblog.dev.
5. Crea una CloudFront Function para la reescritura de URI y pega el siguiente código.

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. Añade comportamientos (behaviors) para /blog, /blog/* y /robots.txt.
7. Publica la función en Live y luego asóciala al evento Viewer request en los tres comportamientos.

Después del despliegue, verifica las siguientes URL desde tu terminal.

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

CloudFront devuelve un error 502

En primer lugar, asegúrate de no haber dejado Origin path vacío. Una conexión de subdirectorio utiliza Custom origin proxy.inblog.dev junto con Origin path /{subdomain}, no un valor CNAME independiente.

Si tu configuración coincide con eso y los errores 502 persisten, comprueba lo siguiente en orden. En la mayoría de los casos falta uno de estos puntos.

1. Los tres comportamientos (/blog, /blog/* y /robots.txt) utilizan el origen proxy.inblog.dev.
2. Los tres comportamientos utilizan la política de solicitud de origen Managed-AllViewerExceptHostHeader. Si se reenvía el encabezado Host del visor, el origen no puede responder a la solicitud.
3. La CloudFront Function está publicada en Live; guardarla no es suficiente.
4. Dicha función está asociada al evento Viewer request en los tres comportamientos.
5. La distribución ha terminado de implementarse (Deployed), incluido tu cambio más reciente.

Si todo lo anterior está correcto y el error 502 continúa, envíanos la salida de los tres comandos siguientes. Comparar una solicitud a través de CloudFront con una solicitud directa al origen nos permite aislar la causa.

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

Configuración de subdirectorio con Apache

Apache no está en la lista de infraestructura del panel, así que elige Otro / Contacto y añade tú mismo las reglas de proxy inverso a Apache. Reemplaza example.com, /blog y {subdomain} con tus propios valores.

En primer lugar, confirma en qué servidor deben ir las reglas. La empresa a la que compraste el dominio (registrador/servidores de nombres) a menudo no es la máquina que realmente sirve tu sitio. Si tus servidores de nombres están con un proveedor de hosting mientras que el sitio web en sí se ejecuta en Apache en una instancia EC2 de AWS, las reglas de proxy van en la configuración de Apache de esa instancia EC2, no en la pantalla de DNS del proveedor de hosting.

Añade lo siguiente al VirtualHost que sirve tu sitio (el VirtualHost del puerto 443 si usas 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" también reenvía todo lo que esté debajo de /blog, por lo que no necesitas una regla independiente para las URL de publicaciones individuales.
• Las dos líneas RequestHeader dentro de <Location "/blog"> le indican a inblog la dirección que los visitantes realmente consultan (example.com) y el subdirectorio bajo el cual se sirve (/blog). El proxy elimina ambos y las analíticas los necesitan para atribuir correctamente las URL de las publicaciones. El enrutamiento nunca los lee, por lo que el blog seguirá funcionando si los omites (requieren mod_headers). Mantenlos dentro del bloque <Location>: en el ámbito del VirtualHost se adjuntarían a cada solicitud en tu propio sitio y podrían alterar la forma en que tu aplicación genera sus URL.
• ProxyPreserveHost Off es la línea fundamental. Si el encabezado Host del visitante se reenvía tal cual, inblog no puede responder a la solicitud. Cumple la misma función que la directiva Managed-AllViewerExceptHostHeader de CloudFront y proxy_set_header Host proxy.inblog.dev de Nginx.
• Omite las reglas de /robots.txt si ya tienes tu propio robots.txt. Consulta ¿La configuración de subdirectorio sobrescribirá mi robots.txt existente? a continuación.

Habilita los módulos necesarios, prueba la configuración y reinicia.

Ubuntu / Debian

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

Amazon Linux / CentOS / RHEL (a menudo los módulos ya están habilitados)

sudo apachectl configtest
sudo systemctl reload httpd

Una vez que ambas URL a continuación devuelvan 200, el estado en la pantalla Dominio de inblog cambiará a Conectado por sí solo.

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

Si no tienes permisos (sudo) para editar el archivo VirtualHost, pide a quien administre el servidor que aplique la configuración anterior.

Mi blog en subdirectorio devuelve ERR_TOO_MANY_REDIRECTS

La ruta del blog está atrapada en un bucle de redirecciones y no carga en absoluto. La causa suele ser una regla de /blog en tu propio sitio. Estas dos son las más comunes.

1. Debe ser un rewrite, no un redirect

Pasar /blog a inblog requiere una reescritura (proxy inverso): la dirección permanece igual y tu servidor responde con el contenido de inblog. Un redirect hace que la solicitud a /blog vuelva a apuntar a /blog, lo que entra en un bucle infinito.

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

2. La forma con www difiere entre inblog y la dirección canónica de tu sitio

Si tu sitio trata example.com (sin www) como canónico pero la dirección registrada en inblog es www.example.com/blog, las redirecciones con www y sin www rebotan entre sí. Elige una sola forma.

• Registra la dirección en la pestaña Dominio de inblog en la misma forma que tu sitio utiliza como canónica.
• Aplica la consolidación de www → sin www en la configuración de redirección de dominios de tu hosting, en una sola dirección, no como una regla específica de /blog.

Cómo saber qué parte está fallando

Compara los encabezados de respuesta para cada dirección. Si el último comando devuelve 200, normalmente son las reglas de redirección de tu sitio las que deben corregirse (consulta la advertencia a continuación para ver la excepción). Si devuelve un código 3xx, debe revisarse el lado de inblog; envíanos ese resultado a través del chat.

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

Si la regla ya es un rewrite y proxy.inblog.dev responde con 200 pero el bucle persiste, comprueba el encabezado location en la respuesta del primer comando. Si te envía de vuelta a la dirección que acabas de solicitar, ningún cambio adicional en tu lado lo solucionará. Deja de editar las reglas y envíanos ese encabezado de respuesta completo a través del chat.

Una Advertencia al comprobar la conexión del dominio en la tarjeta del dominio puede tener la misma causa. También aparece por bloqueos de firewall o fallos transitorios, y se borra sola en la siguiente comprobación una vez que las reglas del proxy estén funcionando. Consulta Qué significa la advertencia de comprobación de conexión en la tarjeta de dominio para ver el desglose mensaje por mensaje.

Mi blog funcionaba ayer y ahora devuelve 404

Nada ha cambiado en inblog, pero todo example.com/blog devuelve 404. La causa más habitual es que un redespliegue, un cambio en la CDN o una modificación del firewall en tu sitio eliminó o sobrescribió la regla de proxy de /blog.

Primero: no desconectes el dominio en inblog. Eliminar y volver a añadir la conexión no restaurará la regla de proxy de tu sitio; solo te obligará a pasar de nuevo por la verificación del dominio.

1. Identifica qué página 404 estás viendo

El aspecto de la página 404 te indica hasta dónde llegó la solicitud.

2. Aísla el lado con fallos mediante una solicitud

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

Si el segundo comando devuelve 200, inblog está bien y solo necesitas restaurar la regla de /blog en tu sitio. Si el segundo comando también falla, envíanos esa salida a través del chat.

3. Revisa lo que ha cambiado recientemente

• Un redespliegue del sitio: si la configuración del proxy no forma parte de la salida de compilación, cada despliegue borra la regla.
• Cambios en las reglas de CDN o WAF, o una política de protección contra bots recién añadida.
• Reemplazo de la configuración del servidor web, renovación de certificados o trabajos similares en el servidor.

4. Comprueba también la advertencia del panel

Si Configuración → Dominio muestra una advertencia, la sección siguiente explica lo que significa cada mensaje.

¿Qué significa la advertencia de comprobación de conexión en la tarjeta de dominio?

inblog comprueba periódicamente si tu dominio conectado realmente sirve este blog, y muestra una Advertencia al comprobar la conexión del dominio en Configuración → Dominio cuando no recibe la respuesta esperada.

La advertencia por sí sola no impide que los visitantes lleguen a tu blog y se borra automáticamente en cuanto una comprobación posterior tiene éxito. Cada mensaje apunta a una causa diferente.

¿La configuración de subdirectorio sobrescribirá mi robots.txt existente?

La guía de configuración incluye una regla que redirige por proxy /robots.txt a inblog junto con las rutas de tu blog (/blog, /blog/*). Esa regla existe para sitios que todavía no tienen un robots.txt. Si ya mantienes el tuyo propio, no la apliques tal cual.

Un dominio tiene solo un robots.txt, servido desde la raíz y aplicado a cada ruta debajo de él. Dirigir por proxy /robots.txt significa que el archivo de inblog responderá en lugar del tuyo, por lo que cualquier regla Disallow que tuvieras dejará de aplicarse.

Si ya tienes un robots.txt, elige una de estas opciones:

1. Elimina solo la regla de /robots.txt (recomendado)

• Mantén las reglas de proxy para las rutas de tu blog (/blog, /blog/*) y elimina únicamente la regla de /robots.txt.
• Añade el mapa del sitio de tu blog a tu robots.txt existente:

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

• Confirma que ninguna de tus reglas Disallow existentes bloquee la ruta del blog (/blog).

2. Mantén el proxy y edita robots.txt dentro de inblog

• Ve a Configuración → Herramientas SEO → Robots.txt en el panel (plan de pago, después de que tu dominio personalizado esté conectado).
• Pega tus reglas existentes allí y mantén la línea del mapa del sitio del blog. Lo que guardes se servirá como respuesta para example.com/robots.txt.
• El editor viene prerrellenado con el valor predeterminado que genera inblog (permitir todos los rastreadores, además de las URL del mapa del sitio). Bórralo por completo y guarda para volver a ese valor predeterminado.

No necesitas mantener el mapa del sitio tú mismo. Con el proxy instalado, inblog vuelve a generar example.com/blog/sitemap.xml cada vez que publicas o editas una entrada. No hay ningún archivo xml que debas subir o actualizar en tu parte.

Subdirectorio y Google Search Console

Cuando conectas un subdirectorio (p. ej., example.com/blog), el tráfico de tu blog se incluye en la propiedad de Search Console del dominio raíz existente. Si quieres analizar por separado solo los datos del blog, puedes añadir una propiedad adicional de tipo Solo esta dirección del blog:

• Tipo de propiedad: URL prefix
• URL: https://example.com/blog

Esta propiedad independiente también requiere su propia verificación con etiqueta HTML. Añade la metaetiqueta de esta propiedad en el panel de inblog, en la pestaña Diseño → Configuración avanzada (Inyección de código).

"Iniciar conexión" no hace nada o aparece un error emergente que bloquea el siguiente paso

Este es el paso previo a los registros DNS: la conexión en sí no se inicia.

Si la solicitud es rechazada, la pantalla Dominio muestra un error cerca del campo de dirección o en una ventana emergente. Comprueba las causas siguientes antes de volver a intentarlo.

Comprueba lo siguiente en orden:

1. Confirma que estás en un plan de pago. Conectar un dominio personalizado es una función de los planes de pago, por lo que las solicitudes de conexión se rechazan en el plan gratuito.
2. Confirma que tu cuenta tenga permiso para conectar dominios. Solo un propietario, administrador o editor de ese blog (con la invitación ya aceptada) puede conectar o desconectar un dominio.
3. No conectes y desconectes repetidamente en un intervalo corto. Las solicitudes de conexión/desconexión de dominios están limitadas a 10 por hora. Tras superar ese límite, cada intento posterior se rechaza y nunca avanza. No hay nada mal configurado; simplemente espera aproximadamente una hora e inténtalo una vez más.
4. Comprueba el formato introducido. La pestaña Subdominio ya incluye el prefijo https://blog., así que introduce solo example.com, sin https:// ni www. La pestaña Subdirectorio espera la ruta completa, como www.example.com/blog.
5. (Subdirectorio) Confirma que el dominio introducido ya se resuelva en internet. Antes de iniciar la conexión, inblog busca la parte del dominio de www.example.com/blog (www.example.com) en el DNS público. Si ese host exacto no tiene ningún registro público A, AAAA o CNAME, la búsqueda falla y la solicitud se rechaza. (Si escribiste www, el registro debe existir en el host www).

Una conexión de subdirectorio superpone tu blog a un sitio que ya está activo. Este paso solo comprueba que el registro DNS exista, pero los pasos posteriores requieren que añadas una regla de proxy inverso en ese sitio. Añade primero el registro DNS que apunta a tu sitio existente, confirma que https://www.example.com se abra con normalidad y luego inicia la conexión. En Cloudflare, ese registro debe estar en modo Proxied.

Si se trata de un dominio nuevo sin ningún sitio detrás todavía, una conexión por subdirectorio no es la opción adecuada, ya que no hay ningún sitio en el que colocar una regla de proxy. Utiliza un subdominio como blog.example.com en su lugar; las conexiones de subdominio y dominio raíz funcionan añadiendo los registros DNS que te proporciona inblog, por lo que no se requiere ningún sitio existente.

¿Qué significa (sin verificar) en la lista de blogs?

Después de añadir registros DNS, el estado del dominio en la lista de blogs del panel de inblog puede mostrar (sin verificar). Esto significa que inblog aún no ha confirmado tus registros DNS. Motivos comunes:

• Los registros DNS aún no se han añadido o los valores son incorrectos.
• La propagación del DNS tarda entre 24 y 48 horas después de realizar los cambios.

Una vez que el estado cambia a (verificado), la confirmación del DNS se ha completado. El dominio puede tardar unos minutos más en ser totalmente accesible.

La pestaña Dominio dice "Emitiendo el certificado SSL". ¿Solo debo esperar?

En la mayoría de los casos, sí. A menos que hayas configurado un registro CAA en el dominio, no queda nada más por hacer. "Emitiendo el certificado SSL" aparece solo después de que se hayan confirmado tus registros DNS, cuando la configuración de HTTPS es el último paso restante. Significa que tus registros ya pasaron la validación.

Para las conexiones de subdominio y dominio raíz, la pestaña Dominio muestra uno de estos cuatro estados de conexión:

Las conexiones de subdirectorio muestran en su lugar un conjunto diferente de tres estados: Se requiere configurar el proxy inverso, Comprobando la conexión del proxy inverso y Conectado.

Los cambios de DNS pueden tardar hasta 24–48 horas en propagarse, y el sitio puede tardar unos minutos más en abrirse tras la emisión del certificado.

• Si has configurado un registro CAA en el dominio, revísalo también, ya que puede bloquear la emisión del certificado.
• Si permanece en "Emitiendo el certificado SSL" durante más de un día, envíanos la dirección que estás conectando junto con una captura de pantalla.

La tarjeta de dominio dice "No se pudieron encontrar servidores de nombres para este dominio."

inblog busca los servidores de nombres del dominio raíz que está detrás de la dirección introducida (p. ej., blog.example.com → example.com) para indicarte en qué servicio de DNS debes añadir los registros. Esta advertencia significa que esa búsqueda no devolvió ningún resultado. Comprueba lo siguiente:

• El dominio está escrito correctamente.
• El dominio está realmente registrado y no ha caducado.
• Los servidores de nombres están asignados en tu registrador de dominios (pueden estar vacíos justo después de la compra).

Esta advertencia solo refleja la búsqueda que utilizamos para indicarte qué servicio de DNS debes usar; no bloquea la verificación. Si el dominio realmente no tiene servidores de nombres asignados, los registros que añadas tampoco se resolverán, así que completa primero la configuración de los servidores de nombres en tu registrador. Si la conexión continúa con normalidad después de añadir los registros, puedes ignorar esta advertencia.

A mí me funciona, pero otras personas no pueden abrir mi blog

A veces, el estado del dominio muestra "Verificado" y el blog se carga correctamente para ti, pero las personas con las que compartes el enlace no pueden acceder a él. Por lo general, esto no es un problema de configuración del dominio: la red en la que se encuentran (Wi-Fi doméstica, operador móvil, red de oficina) todavía tiene el estado anterior en su caché de DNS. Los cambios de DNS se propagan a diferentes velocidades en diferentes redes durante un periodo de hasta 24 a 48 horas, por lo que el DNS público ya puede ser correcto mientras que algunas redes aún no resuelven la dirección.

Qué hacer:

• Comparte la dirección completa (p. ej., https://blog.example.com) en lugar de una parcial.
• Pide a quien no pueda acceder que pruebe con datos móviles en lugar de Wi-Fi, o que lo intente de nuevo un poco más tarde.
• Si sigue fallando en una red específica después de 24–48 horas, envíanos la dirección exacta utilizada y una captura de pantalla del error desde ese entorno.

¿Puedo mover un blog de subdominio a un subdirectorio?

Sí. Cambia el tipo de conexión a Subdirectorio en la pestaña Dominio y registra la nueva dirección (p. ej., example.com/blog). Ten en cuenta que un blog utiliza un tipo de conexión a la vez, por lo que blog.example.com y example.com/blog no pueden funcionar al mismo tiempo.

Qué se actualiza automáticamente

• Los slugs de las publicaciones no cambian. Solo difieren el host y la ruta inicial, por lo que no hay trabajo individual por publicación.
• Las URL canónicas, el mapa del sitio, el RSS y las direcciones de páginas de categorías/autores cambian a la nueva dirección una vez que se verifica la nueva conexión (las cachés pueden tardar unos minutos en actualizarse).
• Las automatizaciones por API y CLI (Make, Zapier, n8n, etc.) no se ven afectadas. Una clave de API está vinculada al blog en sí y no al dominio personalizado, por lo que cambiar el tipo de conexión no la interrumpe.

Qué debes gestionar tú mismo

• Configura tú mismo una redirección permanente (se recomienda 308) desde tu antiguo subdominio personalizado (blog.example.com). Una vez desconectado, inblog ya no responde en ese host, así que añade una regla blog.example.com/{slug} → example.com/blog/{slug} dondequiera que gestiones el dominio o el hosting. Dado que los slugs no cambian, una sola regla que intercambie el host y añada el prefijo /blog es suficiente.
• Apunta primero el registro DNS de blog.example.com fuera de inblog, o la regla de redirección no surtirá efecto; con el CNAME antiguo todavía activo, las solicitudes seguirán dirigiéndose a inblog.
• El dominio predeterminado de inblog (xxx.inblog.io) y tu antiguo dominio personalizado tienen comportamientos de redirección independientes. Para las conexiones de subdominio y dominio raíz, el dominio predeterminado se redirige automáticamente cuando el dominio está verificado y el blog cuenta con un plan Team o superior apto o una prueba activa. En el caso de las conexiones por subdirectorio, las redirecciones del dominio predeterminado dependen de la configuración del proxy: un proxy que use el dominio predeterminado como origen puede entrar en bucle si esa dirección se redirige de vuelta. Contáctanos por el chat para revisar tu configuración antes de confiar en esta redirección. La URL canónica indica de forma independiente la dirección del subdirectorio como la URL preferida. Tu equipo aún debe configurar las redirecciones desde el antiguo dominio personalizado.

¿Se caerá el blog durante el cambio?

Tras verificar la nueva configuración del proxy, comprueba que el blog se cargue en la nueva dirección de subdirectorio. Comprueba también por separado el comportamiento de redirección del dominio predeterminado y las reglas de redirección del antiguo dominio personalizado. Tu sitio web existente no se ve alterado más allá de añadir la regla de ruta /blog.

Los motores de búsqueda necesitan tiempo para volver a indexar una dirección modificada. Configura una redirección permanente desde cada dirección antigua hacia su página nueva correspondiente. Recomendamos 308 para reglas nuevas, pero no necesitas cambiar un 301 existente que funcione correctamente. Las redirecciones señalan la nueva dirección; no garantizan la indexación, las clasificaciones ni el tráfico.

Tras un cambio de dominio, ¿se actualizan también los enlaces y botones de CTA dentro de mis publicaciones?

No: las direcciones escritas dentro de una publicación permanecen tal como están. Las URL canónicas, el mapa del sitio, el RSS y las páginas de categorías/autores se regeneran con el nuevo dominio, pero estos dos elementos se guardan en la propia publicación y no se actualizan solos:

• Las direcciones absolutas en el cuerpo (enlaces, imágenes o botones que apunten a https://old-domain/...)
• La URL en el botón de CTA inferior de cada publicación
• Una URL canónica que hayas escrito manualmente en la publicación. Una canónica por publicación tiene prioridad sobre la generada, por lo que seguirá apuntando al dominio antiguo.

Los CTA inferiores se pueden modificar de forma masiva. En el Gestor de entradas, selecciona las publicaciones y haz clic en Editar para abrir el diálogo de edición masiva; luego activa Configuración del CTA e introduce la nueva dirección en Enlace del CTA para aplicarla a todos los elementos seleccionados a la vez.

• La edición masiva sobrescribe las publicaciones seleccionadas con el mismo valor. No hay una función de buscar y reemplazar que cambie "dominio antiguo → dominio nuevo" publicación por publicación, por lo que si los enlaces difieren, agrupa las entradas que compartan una misma dirección y aplícalas por lotes.
• Los enlaces del cuerpo no están cubiertos por la edición masiva. Abre la publicación y edítalos allí.
• Una redirección permanente en la dirección antigua enviará a los visitantes a la nueva, pero los enlaces guardados en tus entradas seguirán apuntando al dominio antiguo.

Cuando cada publicación tiene un enlace de CTA diferente y solo deseas cambiar el dominio

Si tienes cientos de publicaciones cuyos enlaces de CTA son todos diferentes, de modo que el "mismo valor en todas partes" de la edición masiva no sirve, puedes cambiar únicamente el dominio a través de la API de Posts. No hay necesidad de esperar a una función específica.

1. En el menú de la izquierda, en Configuración → Claves de API, genera una clave de API que incluya los permisos (scopes) posts:read y posts:write.

2. Llama a GET /api/v1/posts página por página con page[number] y page[size] para leer el cta_link de cada publicación.

3. Conserva únicamente las publicaciones cuyo valor contenga el dominio antiguo.

4. Deja intactos la ruta, la consulta (query) y el hash, y sustituye únicamente el dominio por el nuevo.

5. Para cada publicación, envía PATCH /api/v1/posts/{POST_ID} solo con el campo cta_link. El cuerpo de la solicitud se parece a esto:

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

6. Vuelve a leer las publicaciones y confirma que no quede ningún dominio antiguo.

Enviar únicamente cta_link deja intactos el cuerpo, el título y el estado de publicación. Ten en cuenta que sí actualiza el updated_at de cada publicación, por lo que los valores lastmod de tu mapa del sitio cambiarán a esa fecha para cada entrada que proceses. Recomendamos probar primero con unas pocas publicaciones y comprobar el resultado antes de ejecutar el proceso completo. Consulta la documentación de la API para conocer el formato exacto de la solicitud.

Si esto no es algo que puedas ejecutar por tu cuenta, contáctanos por el chat con la dirección de tu blog.

¿No tienes dominio? No hay problema.

Si no tienes un dominio personalizado, sigue usando el dominio de blog predeterminado (p. ej., example.inblog.io) seleccionando la opción "No tengo un dominio" durante la configuración. Puedes actualizar a un dominio personalizado en cualquier momento.

¿Cómo añado una pestaña "Blog" a la navegación de mi sitio web principal?

inblog no controla el menú de navegación de tu sitio web principal. Para añadir un enlace al blog, actualiza la navegación en la herramienta utilizada para crear tu sitio principal (p. ej., Webflow, Framer, WordPress o tu CMS).

Utiliza la dirección de tu blog de inblog como destino del enlace:

• Subdominio: https://blog.example.com
• Subdirectorio: https://example.com/blog

Antes de conectar un dominio personalizado, puedes utilizar temporalmente el dominio predeterminado de inblog, p. ej., https://example.inblog.io.

¿Cómo hago para que el logo del encabezado del blog enlace a mi sitio web principal?

En el panel de inblog, ve a la pestaña Diseño → Encabezado. Allí puedes configurar la imagen del logo y la URL a la que se dirige a los visitantes cuando hacen clic en él. Introduce la URL de tu sitio web principal para redirigir a los visitantes a tu página de inicio.

Última actualización 2026-10-14