Connecter un domaine personnalisé

Connectez votre blog propulsé par inblog à l'aide d'un sous-domaine (par ex. blog.example.com), d'un domaine racine ou d'un sous-répertoire (par ex. example.com/blog), avec des conseils pour la configuration DNS.

Vue d'ensemble

L'étape de configuration du domaine peut nécessiter l'aide d'un développeur, en particulier pour la configuration DNS ou l'implémentation de code. Des sessions d'assistance technique sont disponibles si besoin.

Vous pouvez connecter votre blog propulsé par inblog selon l'une des trois approches suivantes :

• Sous-domaine (par ex. blog.example.com)
• Domaine racine (par ex. example.com)
• Sous-répertoire (par ex. example.com/blog)

Où ajouter les enregistrements DNS : les paramètres DNS doivent être ajoutés là où votre domaine est géré (par ex. Namecheap, GoDaddy, Cloudflare), et non là où votre site web est conçu (par ex. Webflow, Framer). Si vous avez créé votre site sur Webflow mais avez acheté votre domaine auprès de GoDaddy, ajoutez les enregistrements DNS dans GoDaddy.

Où trouver les paramètres de domaine

1. Connectez-vous sur inblog.ai/dashboard. Vous arriverez sur votre liste de blogs.
2. Cliquez sur la carte du blog que vous souhaitez configurer. Les domaines sont configurés par blog, donc si vous en gérez plusieurs, vérifiez que le bon blog est sélectionné.
3. Dans le menu de gauche, sous l'en-tête de groupe Reglages, cliquez sur Domaine. (Vous n'avez pas besoin d'ouvrir l'écran Reglages pour le chercher à l'intérieur — cliquez directement sur Domaine dans le menu de gauche.)
4. En haut de l'écran Domaine, choisissez l'onglet Sous-répertoire, Sous-domaine ou Domaine racine, saisissez votre adresse, puis cliquez sur Démarrer la connexion. Sur l'onglet Sous-répertoire, vous choisissez ensuite l'infrastructure web que vous utilisez, et le guide de reverse proxy correspondant s'affiche étape par étape.

Si l'écran Domaine est grisé et n'accepte aucune saisie, le blog est sur le forfait Free. Les domaines personnalisés sont disponibles sur le forfait Team, y compris pendant l'essai gratuit de 14 jours.

Si cliquer sur la carte ouvre un écran de configuration initiale au lieu de l'écran de gestion, suivez l'étape du domaine à cet endroit. Consultez la section de configuration initiale dans Premiers pas avec inblog pour plus de détails.

Configuration d'un sous-domaine

Dans les paramètres Domaine personnalisé, sélectionnez Sous-domaine et saisissez votre domaine — sans la partie sous-domaine. Le champ est préfixé par un https://blog. fixe, donc saisir example.com ici connecte toujours blog.example.com.

Un blog utilise une seule méthode de connexion à la fois, vous ne pouvez donc pas faire fonctionner blog.example.com et news.example.com côte à côte.

Cliquez sur Démarrer la connexion pour recevoir les instructions de configuration DNS. Ajoutez les enregistrements chez votre fournisseur DNS exactement comme indiqué. Les modifications DNS peuvent prendre jusqu'à 24 heures pour se propager, et inblog vérifie la connexion automatiquement.

Si une autre personne gère votre domaine, utilisez Copier le message de demande sous les enregistrements DNS et envoyez le message à votre développeur ou administrateur de domaine. Il comprend l'adresse et chaque enregistrement qu'ils doivent ajouter.

Si votre fournisseur DNS refuse la valeur CNAME : certains fournisseurs (par ex. Gabia) exigent que la valeur soit un nom de domaine complet (FQDN) et affichent une erreur telle que « la valeur doit se terminer par un point (.) ». Dans ce cas, ajoutez un point final à la valeur exacte fournie par inblog. Par exemple, si inblog affiche abc123.vercel-dns-016.com, saisissez abc123.vercel-dns-016.com.. D'autres fournisseurs (par ex. Imweb) attendent la valeur sans le point final. Suivez le format requis par votre fournisseur.

Puis-je également connecter www, ou ajouter un deuxième domaine ?

Non. Un blog ne possède qu'un seul domaine personnalisé. Pour les connexions par sous-domaine et domaine racine, inblog émet un certificat SSL uniquement pour l'adresse que vous avez enregistrée. Il ne peut pas recevoir et rediriger les requêtes pour une adresse qui n'est pas enregistrée, et il n'y a pas non plus de champ d'alias distinct pour www.

Si vous avez besoin de www.example.com → example.com (par exemple, parce que Google traite déjà la version www comme canonique) :

• Pointer www vers inblog avec un simple CNAME produit une erreur de certificat telle que ERR_CERT_COMMON_NAME_INVALID — www est un nom d'hôte distinct, et aucun certificat n'existe pour lui.

• Laissez uniquement votre adresse canonique enregistrée dans inblog, et pointez www vers le service de redirection de l'entité qui gère votre domaine ou votre hébergement (Cloudflare, Vercel, votre serveur web). Émettez-y un certificat www, puis ajoutez une redirection permanente comme ci-dessous. Nous recommandons la 308 pour les nouvelles règles ; conservez une redirection 301 qui fonctionne correctement, ou utilisez une 301 si votre fournisseur ne prend en charge que celle-ci. Consultez 308 vs 301 et quand utiliser chacune :

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

• Conservez le chemin et la chaîne de requête dans la règle. La direction inverse (example.com → www.example.com) fonctionne de la même manière.

Si vous souhaitez faire fonctionner deux adresses à la fois (par exemple, conserver blog.example.com et ajouter example.com/guide) :

• Créez un deuxième blog et connectez-y la deuxième adresse.
• Les abonnements ainsi que les connexions de domaine sont appliqués par blog dans inblog, donc un abonnement au forfait Team ne peut pas couvrir deux blogs. Le nouveau blog a besoin de son propre abonnement — consultez la FAQ.
• Si une page existe déjà au chemin que vous souhaitez ajouter (par exemple si example.com/guide ouvre actuellement autre chose), la connecter en tant que sous-répertoire remplace ce chemin par inblog. Déplacez la page existante ailleurs ou choisissez un chemin qui est libre.

Configuration d'un sous-répertoire (sous-dossier)

Le tableau de bord fournit actuellement des guides de configuration pour Next.js, Vercel, AWS Amplify, AWS CloudFront, Cloudflare, Nginx, Webflow et Framer. Choisissez Autre / Nous contacter si votre infrastructure n'est pas répertoriée.

Les plateformes prises en charge comprennent :

• Next.js : pris en charge, sauf pour l'export statique
• Vercel / AWS Amplify : pris en charge en tant que plateformes d'hébergement
• Cloudflare : pris en charge lorsque vous pouvez gérer la Zone, le Worker et les Routes du nom d'hôte dans votre propre compte Cloudflare, et que le site web existant fonctionne lorsque son enregistrement DNS est configuré sur Proxied. Voir Cloudflare dans les en-têtes de réponse ou une recherche d'IP ne suffit pas à répondre à cette exigence.
• Framer / Webflow : pris en charge via un reverse proxy utilisant Cloudflare

Avant d'utiliser le guide Cloudflare : continuez uniquement lorsque le site web existant fonctionne déjà en mode Proxied, et que le chemin cible (par exemple, /blog) est inutilisé ou que son contenu et ses URL existants ont été migrés. Un enregistrement DNS only, un constructeur de site SaaS, un autre CDN ou proxy, ou un compte qui ne peut pas gérer la Zone Cloudflare et les Routes de Worker nécessite un examen séparé. Si le nom d'hôte ne peut pas rester proxifié, utilisez plutôt une connexion par sous-domaine.

Le guide de connexion du tableau de bord fournit également une configuration étape par étape pour AWS CloudFront et Nginx.

Si votre environnement n'est pas dans cette liste (Apache, par exemple), choisissez Autre / Nous contacter. Tout serveur web capable de relayer un chemin spécifique vers une origine externe peut être connecté via un reverse proxy personnalisé — contactez-nous par chat et nous validerons la faisabilité avec vous.

Sélectionnez Sous-répertoire dans les paramètres Domaine personnalisé et saisissez votre domaine (par ex. example.com/blog). Cliquez sur Démarrer la connexion pour obtenir le guide de configuration complet. Notez que la configuration d'un sous-répertoire nécessite généralement une implémentation de code.

Le sélecteur d'« infrastructure web » ne change rien du côté d'inblog. Il détermine uniquement quel guide de configuration vous voyez, donc le modifier ultérieurement n'a aucun effet sur un domaine que vous avez déjà connecté.

Si un CDN ou un proxy tel que Cloudflare ou CloudFront est déjà placé devant votre serveur web (Apache, Nginx, etc.), choisissez ce CDN quel que soit le serveur d'origine. Gérer la règle de proxy à l'endroit où les requêtes arrivent en premier est plus simple et laisse la configuration de votre origine intacte.

Mon bureau d'enregistrement de domaine ne figure pas dans la liste « infrastructure web »

C'est normal. La liste demande d'où votre site web est actuellement servi, et non où vous avez acheté le domaine. L'écran indique : « Choisissez l'infrastructure où votre site web est hébergé, puis suivez le guide correspondant ci-dessous. » Il répertorie uniquement les environnements pour lesquels inblog fournit un guide de proxy, de sorte que les bureaux d'enregistrement et fournisseurs DNS tels que Namecheap ou GoDaddy ne sont pas des options ici.

Si votre fournisseur vend à la fois des domaines et de l'hébergement web (Gabia, Cafe24 et similaires), basez-vous sur le serveur web sur lequel tourne réellement votre site — généralement Apache ou Nginx — plutôt que sur le nom du fournisseur. Nginx correspond à Nginx ; Apache, ou tout ce que vous ne pouvez pas confirmer, correspond à Autre / Nous contacter.

La liste contient : NextJS, Vercel, AWS Amplify, AWS CloudFront, Cloudflare, Nginx, Webflow, Framer et Autre / Nous contacter. (Un tableau de bord en coréen affiche également Cafe24 et Imweb ; sélectionner l'un ou l'autre signale que la connexion par sous-répertoire n'est pas disponible pour cet environnement.)

Comment choisir :

1. Si un CDN ou proxy tel que Cloudflare ou AWS CloudFront est placé devant votre site, choisissez ce CDN quel que soit le serveur d'origine.
2. Sinon, choisissez le serveur ou la plateforme qui sert réellement le site (Nginx, Vercel, NextJS, Framer, etc.).
3. Si le site a été conçu avec un outil qui n'est pas répertorié (WordPress, PHP), basez-vous sur le serveur sur lequel il tourne, et non sur l'outil avec lequel il a été créé. WordPress sur Nginx correspond à Nginx ; WordPress sur Apache n'est pas répertorié, choisissez donc Autre / Nous contacter.
4. Si vous ne pouvez pas le déterminer, choisissez Autre / Nous contacter — cela ouvre une discussion avec nous et nous confirmerons la faisabilité ensemble.

Si une agence a créé votre site, demandez-lui deux choses

1. Quel serveur web ou hébergement dessert le site aujourd'hui (Nginx, Apache, Vercel, etc.), et si un CDN tel que Cloudflare ou CloudFront est placé devant.
2. Si elle peut ajouter une règle de reverse proxy (réécriture) pour /blog et /blog/* uniquement. Il doit s'agir d'une réécriture, pas d'une redirection.

Dois-je choisir une infrastructure web pour un sous-domaine ?

Non. Le sélecteur d'infrastructure web n'apparaît que pour les connexions par sous-répertoire.

Les connexions par sous-domaine (blog.example.com) et par domaine racine (example.com) ne touchent jamais au serveur de votre site existant — vous ajoutez uniquement des enregistrements DNS — donc l'écran n'apparaît pas du tout. Si vous voyez la liste des infrastructures, vous êtes actuellement dans le processus du sous-répertoire.

Si vous ne pouvez pas ajouter de règle de proxy sur le serveur de votre site web, passer à une connexion par sous-domaine dans l'onglet Domaine est généralement la voie la plus rapide : elle ne nécessite que des enregistrements DNS auprès de l'entité qui gère votre domaine.

Configuration d'un sous-répertoire avec AWS CloudFront

Pour configurer inblog dans un sous-répertoire à l'aide d'AWS CloudFront, consultez les étapes de configuration suivantes.

1. Utilisez la distribution qui dessert votre site web principal, ou créez une nouvelle distribution si CloudFront n'est pas encore configuré.
2. Définissez Distribution name sur inblog proxy et Domain sur example.com.
3. Définissez Origin type sur Other, Custom origin sur proxy.inblog.dev et Origin path sur /{subdomain}.
4. Définissez l'origin request policy sur Managed-AllViewerExceptHostHeader afin que CloudFront ne transmette pas l'en-tête Host du visiteur à proxy.inblog.dev.
5. Créez une CloudFront Function pour la réécriture d'URI et collez le code suivant.

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. Ajoutez des behaviors pour /blog, /blog/* et /robots.txt.
7. Publiez la fonction sur Live, puis associez-la à l'événement Viewer request pour les trois behaviors.

Après le déploiement, vérifiez les URL suivantes depuis votre terminal.

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

CloudFront renvoie une erreur 502

Tout d'abord, assurez-vous de ne pas avoir laissé Origin path vide. Une connexion par sous-répertoire utilise Custom origin proxy.inblog.dev combiné avec Origin path /{subdomain} — pas une valeur CNAME séparée.

Si vos paramètres correspondent à cela et que les erreurs 502 persistent, vérifiez les points suivants dans l'ordre. L'un d'eux est manquant dans la plupart des cas.

1. Les trois behaviors — /blog, /blog/* et /robots.txt — utilisent l'origine proxy.inblog.dev.
2. Les trois behaviors utilisent l'origin request policy Managed-AllViewerExceptHostHeader. Si l'en-tête Host du visiteur est transmis, l'origine ne peut pas servir la requête.
3. La CloudFront Function est publiée sur Live — l'enregistrer ne suffit pas.
4. Cette fonction est associée à l'événement Viewer request sur les trois behaviors.
5. La distribution a terminé son déploiement (Deployed), y compris votre modification la plus récente.

Si tout ce qui précède est correct et que le 502 persiste, envoyez-nous la sortie des trois commandes ci-dessous. Comparer une requête passant par CloudFront avec une requête adressée directement à l'origine nous permet d'isoler la cause.

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

Configuration d'un sous-répertoire avec Apache

Apache ne figurant pas dans la liste des infrastructures du tableau de bord, choisissez Autre / Nous contacter et ajoutez vous-même les règles de reverse proxy à Apache. Remplacez example.com, /blog et {subdomain} par vos propres valeurs.

Tout d'abord, confirmez sur quel serveur les règles doivent être placées. La société auprès de laquelle vous avez acheté le domaine (bureau d'enregistrement/serveurs de noms) n'est souvent pas la machine qui héberge réellement votre site. Si vos serveurs de noms se trouvent chez un hébergeur alors que le site web lui-même tourne sur Apache sur une instance AWS EC2, les règles de proxy s'intègrent dans la configuration Apache de cette instance EC2, et non dans l'écran DNS de l'hébergeur.

Ajoutez ce qui suit au VirtualHost qui dessert votre site (le VirtualHost du port 443 si vous utilisez 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" transmet également tout ce qui se trouve sous /blog, vous n'avez donc pas besoin d'une règle séparée pour les URL des articles individuels.
• Les deux lignes RequestHeader à l'intérieur de <Location "/blog"> indiquent à inblog l'adresse que les visiteurs parcourent réellement (example.com) et le sous-répertoire sous lequel il est servi (/blog). Le proxy supprime les deux, et les outils d'analyse en ont besoin pour attribuer correctement les URL des articles. Le routage ne les lit jamais, donc le blog continue de fonctionner si vous les omettez (elles nécessitent mod_headers). Conservez-les à l'intérieur du bloc <Location> : au niveau du VirtualHost, elles seraient attachées à chaque requête de votre propre site et pourraient modifier la façon dont votre application construit ses URL.
• ProxyPreserveHost Off est la ligne critique. Si l'en-tête Host du visiteur est transmis tel quel, inblog ne peut pas servir la requête. Elle joue le même rôle que la stratégie Managed-AllViewerExceptHostHeader de CloudFront et le proxy_set_header Host proxy.inblog.dev de Nginx.
• Ignorez les règles /robots.txt si vous gérez déjà votre propre robots.txt. Consultez La configuration d'un sous-répertoire écrasera-t-elle mon robots.txt existant ? ci-dessous.

Activez les modules requis, testez la configuration et rechargez.

Ubuntu / Debian

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

Amazon Linux / CentOS / RHEL (les modules sont souvent déjà activés)

sudo apachectl configtest
sudo systemctl reload httpd

Une fois que les deux URL ci-dessous renvoient un code 200, l'état sur l'écran Domaine d'inblog passe automatiquement à Connecté.

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

Si vous ne disposez pas des autorisations nécessaires (sudo) pour modifier le fichier VirtualHost, demandez à la personne qui gère le serveur d'appliquer la configuration ci-dessus.

Mon blog en sous-répertoire renvoie ERR_TOO_MANY_REDIRECTS

Le chemin du blog est bloqué dans une boucle de redirection et ne se charge pas du tout. La cause est généralement une règle pour /blog sur votre propre site. Ces deux cas sont les plus fréquents.

1. Il doit s'agir d'une réécriture (rewrite), pas d'une redirection (redirect)

Passer /blog à inblog nécessite une réécriture (reverse proxy) — l'adresse reste la même et votre serveur répond avec la réponse d'inblog. Une redirect fait pointer la requête /blog vers /blog, ce qui tourne en boucle à l'infini.

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

2. La forme avec ou sans www diffère entre inblog et l'adresse canonique de votre site

Si votre site traite example.com (sans www) comme canonique mais que l'adresse enregistrée sur inblog est www.example.com/blog, les redirections avec et sans www se renvoient la balle. Arrêtez-vous sur une seule forme.

• Enregistrez l'adresse dans l'onglet Domaine d'inblog sous la même forme que celle utilisée par votre site comme canonique.
• Appliquez l'unification www → sans-www dans les paramètres de redirection de domaine de votre hébergeur, dans une seule direction — pas sous la forme d'une règle spécifique à /blog.

Comment savoir de quel côté vient l'erreur

Comparez les en-têtes de réponse pour chaque adresse. Si la dernière commande renvoie 200, ce sont généralement les règles de redirection de votre site qui doivent être corrigées — voir la mise en garde ci-dessous pour l'exception. Si elle renvoie plutôt un code 3xx, le côté inblog doit être vérifié — envoyez-nous cette sortie par chat.

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

Si la règle est déjà un rewrite et que proxy.inblog.dev répond 200 mais que la boucle persiste, vérifiez l'en-tête location sur la réponse de la première commande. Lorsqu'il vous renvoie à l'adresse que vous venez de demander, aucune modification supplémentaire de votre côté ne réglera le problème. Arrêtez de modifier les règles et envoyez-nous cet en-tête de réponse complet par chat.

Un Avertissement lors de la vérification de la connexion du domaine sur la carte de domaine peut avoir la même cause. Il apparaît également en cas de blocage par un pare-feu ou de pannes transitoires, et s'efface de lui-même lors de la vérification suivante dès que les règles de proxy fonctionnent. Consultez Que signifie l'avertissement de vérification de connexion pour le détail message par message.

Mon blog fonctionnait hier et renvoie maintenant une 404

Rien n'a changé dans inblog, mais l'ensemble de example.com/blog renvoie une 404. La cause la plus fréquente est qu'un redéploiement, une modification du CDN ou un changement de pare-feu sur votre site a supprimé ou écrasé la règle de proxy /blog.

Tout d'abord : ne déconnectez pas le domaine dans inblog. Supprimer et rajouter la connexion ne rétablira pas la règle de proxy de votre site — cela vous obligera seulement à repasser par la vérification du domaine.

1. Identifiez quelle page 404 s'affiche

L'apparence de la page 404 vous indique jusqu'où la requête est allée.

2. Isolez le côté défaillant à l'aide d'une requête

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

Si la deuxième commande renvoie 200, inblog fonctionne correctement et vous n'avez qu'à restaurer la règle /blog sur votre site. Si la deuxième commande échoue également, envoyez-nous cette sortie par chat.

3. Retracez ce qui a changé récemment

• Un redéploiement du site — si la configuration du proxy ne fait pas partie de la sortie de votre build, chaque déploiement efface la règle.
• Modifications des règles CDN ou WAF, ou nouvelle politique de protection contre les robots.
• Remplacement de la configuration du serveur web, renouvellement de certificat ou interventions serveur similaires.

4. Vérifiez également l'avertissement du tableau de bord

Si Reglages → Domaine affiche un avertissement, la section ci-dessous explique la signification de chaque message.

Que signifie l'avertissement de vérification de connexion sur la carte de domaine ?

inblog vérifie régulièrement si votre domaine connecté sert bien ce blog, et affiche un Avertissement lors de la vérification de la connexion du domaine sous Reglages → Domaine lorsqu'il n'obtient pas la réponse attendue.

L'avertissement en lui-même n'empêche pas les visiteurs d'accéder à votre blog, et il disparaît automatiquement dès qu'une vérification ultérieure réussit. Chaque message pointe vers une cause différente.

La configuration d'un sous-répertoire écrasera-t-elle mon robots.txt existant ?

Le guide de configuration inclut une règle qui relaie /robots.txt vers inblog en plus des chemins de votre blog (/blog, /blog/*). Cette règle existe pour les sites qui n'ont pas encore de robots.txt. Si vous gérez déjà le vôtre, ne l'appliquez pas telle quelle.

Un domaine n'a qu'un seul fichier robots.txt, servi depuis la racine et appliqué à tous les chemins situés en dessous. Transmettre /robots.txt signifie que le fichier d'inblog répond à la place du vôtre, de sorte que toutes les règles Disallow que vous aviez cessent de s'appliquer.

Si vous avez déjà un robots.txt, choisissez l'une de ces approches :

1. Supprimez simplement la règle /robots.txt (recommandé)

• Conservez les règles de proxy pour les chemins de votre blog (/blog, /blog/*) et supprimez uniquement la règle /robots.txt.
• Ajoutez le sitemap de votre blog à votre robots.txt existant :

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

• Confirmez qu'aucune de vos règles Disallow existantes ne bloque le chemin du blog (/blog).

2. Conservez le proxy et modifiez le robots.txt dans inblog

• Allez dans Reglages → Outils SEO → Robots.txt dans le tableau de bord (forfait payant, une fois votre domaine personnalisé connecté).
• Collez-y vos règles existantes et conservez la ligne du sitemap du blog. Tout ce que vous enregistrez sera servi en réponse à example.com/robots.txt.
• L'éditeur est pré-rempli avec la configuration par défaut générée par inblog (autoriser tous les robots, plus les URL du sitemap). Videz-le complètement et enregistrez pour revenir à cette valeur par défaut.

Vous n'avez pas besoin de mettre à jour le sitemap vous-même. Avec le proxy en place, example.com/blog/sitemap.xml est regénéré par inblog chaque fois que vous publiez ou modifiez un article. Il n'y a aucun fichier xml à téléverser ou à actualiser de votre côté.

Sous-répertoire et Google Search Console

Lorsque vous connectez un sous-répertoire (par ex. example.com/blog), le trafic de votre blog est inclus dans la propriété Search Console du domaine racine existant. Si vous souhaitez analyser séparément les données propres au blog, vous pouvez ajouter une Uniquement cette adresse de blog supplémentaire :

• Type de propriété : URL prefix
• URL : https://example.com/blog

Cette propriété distincte nécessite également sa propre vérification par balise HTML. Ajoutez la balise meta pour cette propriété dans le tableau de bord inblog sous l'onglet Design → Paramètres avancés (Code injection).

« Démarrer la connexion » ne fait rien, ou une invite d'erreur bloque l'étape suivante

Il s'agit de l'étape située avant les enregistrements DNS — la connexion elle-même ne démarre pas.

Si la demande est rejetée, l'écran Domaine affiche une erreur près du champ d'adresse ou dans une invite. Vérifiez les causes ci-dessous avant de réessayer.

Vérifiez les éléments suivants dans l'ordre.

1. Confirmez que vous êtes sur un forfait payant. La connexion d'un domaine personnalisé est une fonctionnalité des forfaits payants, les demandes de connexion sont donc rejetées sur le forfait gratuit.
2. Confirmez que votre compte est autorisé à connecter des domaines. Seul un propriétaire, administrateur ou éditeur de ce blog — ayant déjà accepté l'invitation — peut connecter ou déconnecter un domaine.
3. Ne connectez et ne déconnectez pas à répétition sur un court intervalle. Les demandes de connexion/déconnexion de domaine sont limitées à 10 par heure. Au-delà de cette limite, chaque nouvelle tentative est rejetée et ne progresse jamais. Rien n'est mal configuré — attendez simplement environ une heure et réessayez une fois.
4. Vérifiez le format de saisie. L'onglet Sous-domaine préfixe déjà le champ par https://blog., ne saisissez donc que example.com — sans https:// ni www. L'onglet Sous-répertoire attend le chemin complet, comme www.example.com/blog.
5. (Sous-répertoire) Confirmez que le domaine saisi se résout déjà sur Internet. Avant de lancer la connexion, inblog résout la partie domaine de www.example.com/blog (www.example.com) dans le DNS public. Si cet hôte exact ne dispose d'aucun enregistrement public A, AAAA ou CNAME, la résolution échoue et la demande est rejetée. (Si vous avez saisi www, l'enregistrement doit exister sur l'hôte www.)

Une connexion par sous-répertoire superpose votre blog sur un site qui est déjà en ligne. Cette étape vérifie uniquement que l'enregistrement DNS existe, mais les étapes suivantes vous demandent d'ajouter une règle de reverse proxy sur ce site. Ajoutez d'abord l'enregistrement DNS pointant vers votre site existant, confirmez que https://www.example.com s'ouvre normalement, puis lancez la connexion. Sur Cloudflare, cet enregistrement doit être défini sur Proxied.

S'il s'agit d'un nouveau domaine sans site configuré derrière, la connexion par sous-répertoire n'est pas adaptée — il n'y a pas de site sur lequel placer une règle de proxy. Utilisez plutôt un sous-domaine tel que blog.example.com ; les connexions par sous-domaine et par domaine racine fonctionnent en ajoutant les enregistrements DNS fournis par inblog, de sorte qu'aucun site existant n'est nécessaire.

Que signifie (non vérifié) dans la liste des blogs ?

Après avoir ajouté les enregistrements DNS, le statut du domaine dans la liste des blogs du tableau de bord inblog peut afficher (non vérifié). Cela signifie qu'inblog n'a pas encore confirmé vos enregistrements DNS. Raisons courantes :

• Les enregistrements DNS n'ont pas encore été ajoutés, ou les valeurs sont incorrectes.
• La propagation DNS prend jusqu'à 24 à 48 heures après la modification.

Une fois que le statut passe à (vérifié), la confirmation DNS est terminée. Le domaine peut nécessiter quelques minutes supplémentaires pour devenir entièrement accessible.

L'onglet Domaine indique « Émission du certificat SSL ». Dois-je simplement attendre ?

Dans la plupart des cas, oui. À moins que vous n'ayez configuré un enregistrement CAA sur le domaine, il n'y a rien d'autre à faire de votre côté. « Émission du certificat SSL » s'affiche uniquement après confirmation de vos enregistrements DNS, lorsque la configuration HTTPS est la dernière étape restante. Cela signifie que vos enregistrements ont déjà passé la validation.

Pour les connexions par sous-domaine et domaine racine, l'onglet Domaine affiche l'un des quatre états de connexion suivants :

Les connexions par sous-répertoire affichent quant à elles un ensemble distinct de trois états : Configuration du reverse proxy requise, Vérification de la connexion du reverse proxy et Connecté.

Les modifications DNS peuvent prendre de 24 à 48 heures pour se propager, et le site peut mettre quelques minutes supplémentaires à s'ouvrir après l'émission du certificat.

• Si vous avez défini un enregistrement CAA sur le domaine, vérifiez-le également — il peut bloquer l'émission du certificat.
• S'il reste bloqué sur « Émission du certificat SSL » pendant plus d'une journée, envoyez-nous l'adresse que vous connectez accompagnée d'une capture d'écran.

La carte de domaine indique « Impossible de trouver les serveurs de noms pour ce domaine »

inblog recherche les serveurs de noms du domaine racine correspondant à l'adresse que vous avez saisie (par ex. blog.example.com → example.com) afin de pouvoir vous indiquer auprès de quel service DNS ajouter les enregistrements. Cet avertissement signifie que cette recherche n'a rien renvoyé. Vérifiez les éléments suivants :

• Le domaine est correctement orthographié.
• Le domaine est réellement enregistré et n'a pas expiré.
• Des serveurs de noms sont assignés chez votre bureau d'enregistrement (ils peuvent être vides juste après l'achat).

Cet avertissement reflète uniquement la recherche que nous utilisons pour vous indiquer quel service DNS utiliser — il ne bloque pas la vérification. Si le domaine n'a véritablement aucun serveur de noms assigné, les enregistrements que vous ajoutez ne se résoudront pas non plus ; terminez donc d'abord la configuration des serveurs de noms chez votre bureau d'enregistrement. Si la connexion se poursuit normalement après l'ajout des enregistrements, vous pouvez ignorer cet avertissement.

Cela fonctionne pour moi, mais d'autres personnes ne peuvent pas ouvrir mon blog

Il arrive que le statut du domaine affiche « Vérifié » et que le blog se charge correctement pour vous, mais que les personnes avec lesquelles vous partagez le lien ne puissent pas y accéder. Il ne s'agit généralement pas d'un problème de configuration de domaine — le réseau sur lequel elles se trouvent (Wi-Fi domestique, opérateur mobile, réseau d'entreprise) conserve encore l'ancien état dans son cache DNS. Les modifications DNS se diffusent à des vitesses différentes selon les réseaux pendant 24 à 48 heures, de sorte que le DNS public peut déjà être à jour alors que certains réseaux ne parviennent pas encore à résoudre l'adresse.

Que faire :

• Partagez l'adresse complète (par ex. https://blog.example.com) plutôt qu'une adresse partielle.
• Demandez aux personnes qui ne parviennent pas à y accéder d'essayer avec les données mobiles plutôt que le Wi-Fi, ou de réessayer un peu plus tard.
• Si le problème persiste sur un réseau spécifique après 24 à 48 heures, envoyez-nous l'adresse exacte utilisée et une capture d'écran de l'erreur depuis cet environnement.

Puis-je déplacer un blog sous-domaine vers un sous-répertoire ?

Oui. Basculez le type de connexion sur Sous-répertoire dans l'onglet Domaine et enregistrez la nouvelle adresse (par ex. example.com/blog). Notez qu'un blog utilise un seul type de connexion à la fois, de sorte que blog.example.com et example.com/blog ne peuvent pas fonctionner simultanément.

Ce qui suit automatiquement

• Les slugs des articles ne changent pas. Seuls l'hôte et le chemin de tête diffèrent, il n'y a donc aucun travail article par article.
• Les URL canoniques, le sitemap, le flux RSS et les adresses des pages de catégories/auteurs basculent vers la nouvelle adresse une fois la nouvelle connexion vérifiée (les caches peuvent mettre quelques minutes à s'actualiser).
• Les automatisations API et CLI (Make, Zapier, n8n, etc.) ne sont pas affectées. Une clé API est liée au blog lui-même plutôt qu'au domaine personnalisé, donc changer le type de connexion ne l'interrompt pas.

Ce que vous devez gérer vous-même

• Configurez vous-même une redirection permanente (308 recommandée) depuis votre ancien sous-domaine personnalisé (blog.example.com). Une fois déconnecté, inblog ne répond plus sur cet hôte, ajoutez donc une règle blog.example.com/{slug} → example.com/blog/{slug} là où vous gérez le domaine ou l'hébergement. Les slugs restant inchangés, une seule règle qui permute l'hôte et préfixe /blog suffit.
• Pointez d'abord l'enregistrement DNS de blog.example.com ailleurs que vers inblog, sinon la règle de redirection ne prendra pas effet — avec l'ancien CNAME toujours en place, les requêtes continuent de se diriger vers inblog.
• Le domaine inblog par défaut (xxx.inblog.io) et votre ancien domaine personnalisé ont des comportements de redirection distincts. Pour les connexions par sous-domaine et par domaine racine, le domaine par défaut redirige automatiquement lorsque le domaine est vérifié et que le blog dispose d'un forfait Team ou supérieur éligible ou d'un essai actif. Pour les connexions par sous-répertoire, les redirections du domaine par défaut dépendent de la configuration du proxy : un proxy utilisant le domaine par défaut comme origine peut créer une boucle si cette adresse redirige en retour. Contactez-nous par chat pour vérifier votre configuration avant de vous fier à cette redirection. L'URL canonique signale séparément l'adresse du sous-répertoire comme URL préférée. Votre équipe doit tout de même configurer les redirections depuis l'ancien domaine personnalisé.

Le blog sera-t-il indisponible pendant la transition ?

Après avoir vérifié la nouvelle configuration du proxy, assurez-vous que le blog se charge à la nouvelle adresse de sous-répertoire. Vérifiez également de manière distincte le comportement de redirection du domaine par défaut et les règles de redirection de l'ancien domaine personnalisé. Votre site web existant n'est pas modifié en dehors de l'ajout de la règle de chemin /blog.

Les moteurs de recherche ont besoin de temps pour réindexer une adresse modifiée. Configurez une redirection permanente de chaque ancienne adresse vers la nouvelle page correspondante. Nous recommandons la 308 pour les nouvelles règles, mais vous n'avez pas besoin de changer une redirection 301 existante qui fonctionne correctement. Les redirections signalent la nouvelle adresse ; elles ne garantissent pas l'indexation, les classements ou le trafic.

Après un changement de domaine, les liens et les boutons CTA dans mes articles sont-ils également mis à jour ?

Non — les adresses écrites dans le contenu d'un article restent telles quelles. Les URL canoniques, le sitemap, le flux RSS et les pages de catégories/auteurs sont regénérés avec le nouveau domaine, mais ces deux éléments sont stockés sur l'article lui-même et ne s'adaptent pas automatiquement :

• Les adresses absolues dans le corps de texte (liens, images ou boutons pointant vers https://old-domain/...)
• L'URL sur le bouton CTA au bas de chaque article
• Une URL canonique que vous avez saisie vous-même dans l'article. Une URL canonique définie par article a la priorité sur celle qui est générée, elle continuera donc à pointer vers l'ancien domaine.

Les CTA du bas peuvent être modifiés en bloc. Dans Gestion des articles, sélectionnez les articles et cliquez sur Modifier pour ouvrir la fenêtre de modification en bloc, puis activez Paramètres du CTA et saisissez la nouvelle adresse sous Lien du CTA pour l'appliquer à l'ensemble de votre sélection en une seule fois.

• La modification en bloc écrase les articles sélectionnés avec la même valeur. Il n'y a pas d'outil de recherche et remplacement qui permute « ancien domaine → nouveau domaine » par article ; si les liens diffèrent, regroupez les articles partageant une même adresse et appliquez-les par lots.
• Les liens dans le corps du texte ne sont pas couverts par la modification en bloc. Ouvrez l'article pour les y modifier.
• Une redirection permanente sur l'ancienne adresse envoie les visiteurs vers la nouvelle, mais les liens enregistrés dans vos articles continueront de pointer vers l'ancien domaine.

Lorsque chaque article a un lien CTA différent et que vous souhaitez seulement changer le domaine

Si vous avez des centaines d'articles dont les liens CTA diffèrent tous, de sorte que l'option « même valeur partout » de la modification en masse ne convient pas, vous pouvez changer uniquement le domaine via l'API Posts. Il n'est pas nécessaire d'attendre une fonctionnalité dédiée.

1. Dans le menu de gauche sous Reglages → Clés API, générez une clé API qui inclut les portées posts:read et posts:write.

2. Appelez GET /api/v1/posts page par page avec page[number] et page[size] pour lire le champ cta_link de chaque article.

3. Ne conservez que les articles dont la valeur contient l'ancien domaine.

4. Laissez le chemin, la requête et l'ancre intacts et remplacez uniquement le domaine par le nouveau.

5. Pour chaque article, envoyez PATCH /api/v1/posts/{POST_ID} avec uniquement le champ cta_link. Le corps de la requête ressemble à ceci :

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

6. Relisez les articles pour confirmer qu'il ne reste aucun ancien domaine.

Envoyer uniquement cta_link laisse le corps, le titre et l'état de publication intacts. Notez que cela met à jour le champ updated_at de chaque article, de sorte que les valeurs lastmod de votre sitemap basculent sur cette date pour chaque article traité. Nous vous recommandons d'essayer d'abord sur quelques articles et de vérifier le résultat avant d'exécuter l'ensemble. Consultez la documentation de l'API pour le format de requête exact.

Si vous ne pouvez pas exécuter cela vous-même, contactez-nous par chat en indiquant l'adresse de votre blog.

Pas de domaine ? Pas de problème.

Si vous n'avez pas de domaine personnalisé, continuez à utiliser le domaine de blog par défaut (par ex. example.inblog.io) en sélectionnant l'option « I don't own a domain » lors de la configuration. Vous pouvez passer à un domaine personnalisé à tout moment.

Comment ajouter un onglet « Blog » à la navigation de mon site web principal ?

inblog ne contrôle pas le menu de navigation de votre site web principal. Pour ajouter un lien de blog, mettez à jour la navigation dans l'outil utilisé pour concevoir votre site principal (par ex. Webflow, Framer, WordPress ou votre CMS).

Utilisez l'adresse de votre blog inblog comme cible de lien :

• Sous-domaine : https://blog.example.com
• Sous-répertoire : https://example.com/blog

Avant de connecter un domaine personnalisé, vous pouvez temporairement utiliser le domaine inblog par défaut, par ex. https://example.inblog.io.

Comment faire en sorte que le logo de l'en-tête du blog renvoie vers mon site web principal ?

Dans le tableau de bord inblog, rendez-vous dans l'onglet Design → En-tête. Vous pouvez y définir l'image du logo et l'URL vers laquelle les visiteurs sont dirigés lorsqu'ils cliquent dessus. Saisissez l'URL de votre site web principal pour rediriger les visiteurs vers votre page d'accueil.

Dernière mise à jour 2026-10-14