Un site qui fonctionne sur localhost reste sur votre ordinateur. Pour partager des fichiers HTML et CSS, il faut les publier sur un hébergement accessible aux navigateurs des visiteurs. Le site publié ne dépend plus de votre ordinateur allumé.
Ce tutoriel utilise un exemple original sous licence MIT. Consultez la démonstration publiée et ouvrez directement sa deuxième page. Cet exemple ne comprend ni connexion utilisateur, ni base de données, ni traitement de formulaire.
Si votre projet utilise React et Vite, suivez le guide de publication depuis Git et des routes de navigateur, avec un exemple construit et publié sur Hostbrid.
Si vous avez créé le site pour un client, la checklist de remise d’un site statique aide à vérifier le domaine, les comptes, le code et les responsabilités.
1. Vérifiez que le site est du HTML statique
L’exemple contient index.html, about.html et styles.css à la racine du dépôt. Les liens utilisent des chemins relatifs, comme styles.css et about.html. Un chemin vers /Users/... ou localhost dépend de votre ordinateur et ne sera pas accessible aux visiteurs.
Si votre outil d’IA a produit package.json, une API serveur ou un backend externe, ces étapes peuvent être insuffisantes. Consultez quel hébergement choisir pour un site créé avec une IA. Conservez les services dont l’application dépend plutôt que de les supprimer pour obtenir un site statique.
2. Placez les fichiers dans votre dépôt
Copiez l’exemple ou créez un fork dans votre compte GitHub, en conservant la licence. Remplacez les contenus et images de démonstration, puis vérifiez que index.html se trouve à la racine de la branche à publier. Ne mettez pas de mots de passe, de clés privées ou de données clients dans le dépôt.
Projects utilise des dépôts Git. Télécharger un ZIP ne signifie pas que le panneau propose un envoi direct de ZIP. La documentation de Projects décrit la connexion au fournisseur et la sélection du dépôt. Vérifiez les autorisations accordées.
3. Configurez cet exemple HTML
Utilisez le préréglage HTML simple (estatico). Voici les valeurs vérifiées pour ces fichiers :
| Paramètre | Valeur pour cet exemple |
|---|---|
| Branche | main |
| Commande d’installation | Vide |
| Commande de construction | Vide |
| Dossier de sortie | . |
| Sous-dossier du dépôt | Vide |
N’ajoutez pas npm ci ou npm run build : cet exemple n’a ni dépendances à installer ni compilation. Si vos fichiers sont dans un autre dossier, adaptez la racine et la sortie. . n’est pas le dossier de sortie adapté à tous les frameworks.
4. Vérifiez l’adresse publique
Ouvrez l’adresse HTTPS du projet depuis un autre appareil. Vérifiez l’accueil, saisissez /about.html directement, rechargez la page, suivez les liens et assurez-vous que les styles se chargent. Vérifiez aussi l’affichage mobile. Le statut « publié » ne suffit pas : notre première requête a renvoyé 404 avant que les vérifications suivantes ne servent correctement la démonstration.
Test du 8 octobre 2026 : nous avons téléchargé le commit cca391c, publié avec ces réglages et vérifié les deux pages et le CSS en HTTPS, la navigation et les largeurs de 390 et 1280 px. Le test a utilisé le compte interne de Hostbrid. Il confirme la construction et la publication, mais pas le parcours OAuth d’un client ni les mises à jour déclenchées par un push.
Publié ne signifie pas indexé
Une URL accessible en HTTPS permet de vérifier la publication. Elle ne démontre ni son indexation par Google ni une position particulière dans les résultats. Changer d’hébergement ne garantit pas non plus les recommandations d’une IA.
Comparez le HTML reçu dans la réponse au DOM affiché après l’exécution de JavaScript dans le navigateur. Un texte peut être présent dès le départ ou apparaître ensuite grâce à un script. Selon la documentation JavaScript de Google, Google peut le traiter : l’absence de ce texte dans le HTML initial ne prouve pas que Google ne peut pas le voir. Le voir dans votre navigateur ne prouve pas davantage que Google a rendu cette page.
Pour une page délibérément destinée à la recherche, vérifiez statut HTTP, balise meta robots et en-tête X-Robots-Tag. Un noindex initial compte même si JavaScript le retire ensuite : Google peut omettre le rendu lorsqu’il le rencontre. Consultez les instructions empêchant l’indexation avant de les modifier. Ne placez pas noindex dans robots.txt et ne retirez pas les restrictions des pages privées ou volontairement exclues. Si l’exploration est bloquée, Google peut ne pas lire l’instruction de la page.
Dans Search Console, examinez l’URL avec son responsable autorisé. Distinguez le résultat enregistré d’une inspection en direct : ce sont des vérifications différentes, et une requête API ne demande pas automatiquement l’indexation. Un HTTP200 sans noindex ne prouve toujours ni indexation ni classement. Consignez vos observations, puis poursuivez les vérifications de formulaire ou de domaine pertinentes.
Consultez l’essai original MIT : six routes synthétiques comparent HTML statique, texte ajouté par JavaScript, noindex en meta ou en en-tête, une balise initiale retirée par JavaScript et un véritable HTTP404. Les réponses HTTP et douze vues Chrome ont été vérifiées à 390 et 1280 px. Dans le cas du retrait, Chrome affiche le texte et supprime la balise, sans démontrer que Google fait de même. Pour reproduire uniquement cet essai local, suivez le README avec Node 22.23.3, npm 10.9.9 et Chrome ; la version testée était 154.0.8037.98. Ce n’est ni un export Lovable ni une preuve d’exploration, d’indexation ou de livraison native chez Hostbrid.
Formulaires et domaine personnalisé
Le lien de contact ouvre un logiciel de messagerie ; il ne traite pas de formulaire. Connexion utilisateur, paiements et envoi de données nécessitent des services supplémentaires et leurs propres tests. Un domaine personnalisé dépend des conditions du forfait, avec des frais d’enregistrement et de renouvellement distincts : consultez les offres actuelles. Pour ce parcours de publication depuis Git, découvrez Hostbrid Projects.