Notes de terrain · Conception de sites web
Wix headless avec Astro : ce que la refonte de quatre sites m’a appris
Quatre sites web ont quitté l’éditeur Wix pour passer sur Astro headless géré par Wix. Ce que j’ai mesuré, ce qui s’est cassé sans qu’aucune documentation ne m’avertisse, et comment déterminer si votre site devrait faire ce même pas.
Au cours des deux derniers mois, j’ai déplacé quatre sites web hors de l’éditeur Wix : deux sites D'Argenta (dargentaawards.com et dargentaenterprise.com), la boutique de Donna Roffe (donnaroffe.com) et ce site. Wix gère toujours tout derrière les pages — réservations, formulaires, médias, catalogue de la boutique, domaine. Les pages elles-mêmes sont désormais des rendus côté serveur Astro standard.
Pourquoi quitter l’éditeur : les chiffres
Une page dans l’éditeur Wix livre l’intégralité du runtime Wix avec elle. Avant la refonte, chaque page de ce site faisait 0,8–1,0 Mo de HTML à elle seule et chargeait 195–255 fichiers. Les sites D'Argenta étaient dans la même gamme : environ 1 Mo de HTML par page sur Awards, et 541–972 Ko pour la page Enterprise que j’ai échantillonnée.
Après la refonte, les pages d’accueil mesurent :
simonabrahamworks.com
- HTML (compressé)
- 14.5 Ko
- Requêtes (mobile)
- 23
- Lighthouse mobile
- 91
- Lighthouse desktop
- 98
dargentaawards.com
- HTML (compressé)
- 20 Ko
- Requêtes (mobile)
- 29
- Lighthouse mobile
- 83
- Lighthouse desktop
- 95
dargentaenterprise.com
- HTML (compressé)
- 22 Ko
- Requêtes (mobile)
- 28
- Lighthouse mobile
- 80
- Lighthouse desktop
- 96
donnaroffe.com
- HTML (compressé)
- 13.5 Ko
- Requêtes (mobile)
- 35
- Lighthouse mobile
- 82
- Lighthouse desktop
- 98
| Site | HTML (compressé) | Requêtes (mobile) | Lighthouse mobile | Lighthouse desktop |
|---|---|---|---|---|
| simonabrahamworks.com | 14.5 Ko | 23 | 91 | 98 |
| dargentaawards.com | 20 Ko | 29 | 83 | 95 |
| dargentaenterprise.com | 22 Ko | 28 | 80 | 96 |
| donnaroffe.com | 13.5 Ko | 35 | 82 | 98 |
Lighthouse 12, page d’accueil, médiane de trois exécutions par site et appareil, 7 octobre 2026. Les chiffres en laboratoire varient de quelques points entre les exécutions ; l’écart ci-dessous ne bouge pas.
Pour comparaison, une boutique dans l’éditeur Wix avec laquelle je travaille, mesurée le même jour avec le même outil : 2,9 Mo de HTML (411 Ko compressés), 396 requêtes sur mobile, Lighthouse 32 sur mobile et 42 sur desktop.
L’accessibilité, les bonnes pratiques et le SEO ont obtenu des scores de 96–100 sur les quatre sites refondus.
La vitesse est la partie visible. Le changement plus important réside dans le contrôle : chaque titre, description, en-tête, taille d’image et ligne de données structurées est désormais écrit par moi, et non décidé par l’éditeur.
La configuration
Wix headless géré signifie que Wix héberge le site Astro, gère l’authentification et les variables d’environnement, et donne au code un accès direct aux mêmes applications métier que celles utilisées par l’éditeur.
Ce qui a fonctionné
- Lier votre propre projet
- Commencez avec votre propre projet Astro et exécutez npm create @wix/new@latest -- headless link. Cela crée une nouvelle entreprise et un nouveau site Wix pour le projet.
- Astro 5 ou 7
- L’intégration Wix prend en charge Astro 5 et 7 ; Astro 6 est ignoré. Ces sites tournent sur Astro 7.
- Rendu côté serveur
- Utilisez l’adaptateur d’hébergement Wix avec une sortie de rendu côté serveur, afin que les pages soient rendues à la demande et affichent toujours des données en direct.
- Gardez Wix pour le business
- Les réservations, la boîte de réception des contacts, les médias et le catalogue de la boutique restent dans le tableau de bord Wix. Le site les lit et les écrit via les API Wix, de sorte qu’une réservation effectuée sur le nouveau site arrive dans le calendrier de réservation Wix comme n’importe quelle autre.
- Déployer en une commande
- Chaque projet possède un script qui exécute les vérifications, commit sur GitHub, build et release. Rien n’est mis en ligne s’il n’est pas sous contrôle de version.
Une chose a changé pendant le projet : la version 1.1.254 de la CLI Wix a ajouté une commande finalize-migration, dernière étape pour déplacer un site éditeur existant vers un front-end headless sur le même site Wix, au lieu d’un nouveau. Jusqu’alors, chaque projet headless commençait comme un nouveau site Wix. Wix ne l’a pas encore documenté ; je le rédigerai une fois que je l’aurai testé de bout en bout.
Ce qui casse en production
Aucun de ces problèmes n’apparaît sur votre ordinateur portable. Tous sont apparus sur un domaine en direct.
Cinq pièges
- Wix répond d’abord pour certains fichiers
- robots.txt, llms.txt, sitemap.xml et favicon.ico sont servis par la couche edge de Wix, et non par votre code, de sorte qu’une route Astro pour ces fichiers ne fait rien. Configurez robots.txt et llms.txt dans les paramètres SEO de Wix ou via leurs API, et liez vos icônes dans le head de la page : le /favicon.ico de Wix reste vide quel que soit ce que vous téléchargez.
- Le site croit être sur http
- Wix termine la connexion HTTPS avant que la requête n’atteigne Astro, donc Astro.url renvoie http://. Chaque canonical, lien hreflang et image de partage construite à partir de celui-ci était erroné. Codifiez l’origine de production en un seul endroit et construisez chaque URL absolue à partir de celle-ci.
- Wix ajoute ses propres balises SEO
- Wix injecte un second title, description, canonical et ses propres données structurées pour la page d’accueil par-dessus les vôtres. Deux canonicals valent pire qu’aucun, de sorte qu’une petite étape de middleware supprime les copies de Wix.
- Les en-têtes de cache sont ignorés
- J’ai défini s-maxage pour que la couche edge mette en cache le HTML. Cela ne s’est jamais produit. Le temps de réponse du serveur était de 0,3–0,6 s sans cela, donc j’ai supprimé le code plutôt que de garder quelque chose qui semblait fonctionner mais pas vraiment.
- Votre sitemap n’est pas celui de Wix
- Wix garde /sitemap.xml pour lui-même. Publiez votre propre index sous un autre chemin, tel que /sitemap-index.xml, pointez robots.txt dessus, et soumettez-le à Google et Bing.
SEO, fait volontairement
Trois des quatre sites de l’éditeur avaient le même défaut : le texte du corps était traduit dans toutes les langues, mais le title et la meta description ne l’étaient pas. La page d’accueil Awards portait un seul title à travers 23 langues ; la page d’accueil Enterprise, un seul title à travers 99. La boutique de Donna Roffe avait un problème différent : 18 pages partageaient 6 titles, et Google n’en avait indexé qu’une seule.
Ce que fait chaque refonte maintenant
- Un H1, des titles uniques
- Un seul H1 par page, et un title et une description uniques dans chaque langue.
- Un graph relié
- Les données structurées comme un seul graph lié — Person ou Organization, WebSite, WebPage, breadcrumbs, et Product ou Service là où ils s’appliquent — au lieu de snippets déconnectés.
- Les langues dans le sitemap
- hreflang réside uniquement dans les sitemaps XML, et n’est pas répété dans le head de chaque page, afin qu’il y ait une seule source de vérité à maintenir cohérente.
- 301 pour chaque ancienne URL
- Les slugs de l’éditeur comme /contact-8 et /copy-of-website-design deviennent des chemins propres, et rien de ce qui était déjà classé n’est perdu.
- IndexNow à chaque release
- Après chaque déploiement, le site envoie sa liste complète d’URL à Bing et aux autres moteurs IndexNow, afin que les changements soient pris en compte en minutes au lieu de semaines.
- Un llms.txt
- Un résumé en texte brut de qui possède le site et ce que chaque page répond, pour les assistants IA qui le lisent.
Plus d’une langue, incluant de droite à gauche
Ce site fonctionne en anglais, espagnol (Mexique) et hébreu. Awards fonctionne en 23 langues et Enterprise en 98.
Ce que cela demande
- Une URL par langue
- Chaque langue obtient sa propre URL (/es/…, /he/…), son propre title et description, et sa propre entrée dans le sitemap.
- Vraiment de droite à gauche
- Les pages hébreues définissent dir="rtl" sur le document, et la mise en page suit la direction de lecture au lieu d’être bricolée après coup.
- Surveillez la direction mixte
- Une abréviation latine entre parenthèses à l’intérieur d’une phrase hébreue peut se réordonner de manière absurde. Testez chaque chaîne hébreue dans un navigateur, pas dans l’éditeur.
- Le Mexique, pas l’Espagne
- L’ancien site déclarait es-ES ; l’audience est mexicaine, donc c’est es-MX.
Est-ce que cela en vaut la peine pour votre site ?
- Cela en vaut la peine quand
- Le site génère des revenus ou des prospects depuis la recherche et que les limites de vitesse ou de SEO de l’éditeur vous coûtent ; vous avez besoin de plusieurs langues faites correctement ; ou vous voulez que le site soit sous contrôle de version, avec chaque changement revu et réversible.
- Cela n’en vaut pas la peine quand
- Vous changez la mise en page vous-même chaque semaine et ne voulez pas un développeur dans la boucle ; le site dépend d’applications spécifiques à l’éditeur ou de Wix Members, qui ne se déplacent pas entre sites Wix ; ou un petit site vitrine charge déjà vite et est bien classé pour votre nom.
Vous mesurez le pour et le contre pour votre propre site Wix ?
Réservez une heure et nous pouvons l’examiner ensemble.