Inventorier les services Squarespace avant un export statique

Un export statique de Squarespace est une bonne façon de garder une copie portable d’un site et de préparer un autre hébergement. Mais les fichiers HTML, CSS, JavaScript et médias ne remplacent pas automatiquement les services qui traitent des données côté serveur. Avant de déplacer un domaine, faites donc l’inventaire de ces services, choisissez leur remplaçant ou leur sort, puis validez l’export sur une adresse de test. C’est le moyen le plus sûr de conserver l’apparence du site sans promettre des fonctions qui n’existent plus.

Pour cette opération, l’exporteur Squarespace d’ExFlow capture le site publié et permet de récupérer ses pages et ses ressources en fichiers statiques. Il est particulièrement utile quand l’objectif est une archive vérifiable, une remise au client ou un déploiement versionné. La condition est de distinguer ce qui est servi au visiteur de ce qui dépend encore de Squarespace ou d’un tiers.

Pourquoi commencer par un inventaire des services

Une page visible peut très bien survivre à un export alors qu’une action associée ne survit pas. Un bouton de contact, par exemple, peut rester à sa place mais ne plus envoyer de message. Le bon réflexe consiste à considérer le site comme deux dossiers :

Dossier	Question à poser	Décision avant publication
Contenu et présentation	La page, ses images et ses styles sont-ils présents ?	Contrôler le rendu et les liens.
Service actif	Que se passe-t-il après le clic ou la soumission ?	Conserver, remplacer, désactiver ou signaler.

ExFlow indique que l’export comprend les pages publiques, les styles, scripts, médias, polices et autres fichiers liés du site publié. Son fonctionnement est donc adapté à une copie statique ; la documentation d’ExFlow précise aussi les limites importantes : les soumissions de formulaires, le paiement Commerce, les espaces membres, la prise de rendez-vous et la recherche restent des services à recréer ou à rediriger. Ne les traitez pas comme des détails de finition.

Cette préparation complète utilement le dossier Squarespace à constituer avant une migration : le dossier rassemble les preuves ; l’inventaire ci-dessous transforme ces preuves en décisions de fonctionnement.

La fiche d’inventaire à remplir avant l’export

Parcourez le site public, son menu et ses pages de campagne. Pour chaque élément actif, notez l’URL, le propriétaire, le comportement attendu, la destination actuelle et la décision. Une ligne par service suffit.

1. Formulaires et newsletter. Envoyez un essai avec une adresse de test. Notez où arrive le message, quelles notifications partent et quel consentement est affiché. Après la bascule, pointez le formulaire vers un nouvel endpoint ou une solution de formulaire ; sinon, retirez-le temporairement.
2. Commerce et paiements. Ajoutez un produit au panier sans finaliser de paiement. Un catalogue statique peut rester consultable, mais un tunnel de commande a besoin d’un système de paiement actif. Choisissez entre conserver une boutique hébergée, lier vers un checkout externe ou différer la bascule.
3. Espace membre, agenda et recherche. Connectez-vous avec un compte de test, faites une recherche et essayez une réservation. Ces fonctions personnalisées ne doivent jamais être validées par le seul rendu visuel.
4. Scripts de mesure et de consentement. Relevez les outils chargés dans le navigateur : statistiques, pixels, bannière de consentement, chat ou cartes. Décidez lesquels sont nécessaires, compatibles avec le nouvel hébergeur et correctement déclarés.
5. Liens sortants et redirections. Gardez une petite carte des anciennes URL et de leur destination. Elle évite qu’une page de campagne, un PDF ou un ancien partage social devienne une impasse.

Le format est réutilisable : service → page concernée → test → propriétaire → décision → preuve. Il rend la remise au client explicable et évite de confondre un export réussi avec une migration fonctionnelle.

Exporter une copie testable, pas seulement une archive

Quand l’inventaire est prêt, lancez l’export depuis l’URL publiée dans ExFlow. Vérifiez que les options de pages, CSS, JavaScript et médias correspondent au périmètre du site. Pour un site protégé par mot de passe en façade, ExFlow prévoit le mot de passe de front-end ; un site entièrement non publié reste hors de portée.

Téléchargez d’abord le ZIP ou envoyez la copie vers un dépôt Git, un bucket S3 ou un serveur FTP. Ne changez pas encore le DNS. Ouvrez la copie sur une URL de préproduction et comparez-la au site source. Cette séparation entre copie et bascule rejoint la logique de la checklist de livrable Framer auto-hébergeable : un paquet de fichiers n’est livrable que si ses comportements annoncés ont été vérifiés.

Contrôle de réception : les cinq passages utiles

Effectuez ces contrôles sur la copie déployée, dans un navigateur normal et sur mobile :

• Ouvrez les pages principales, les articles, les galeries et les pages profondes depuis le menu puis depuis un lien direct.
• Contrôlez les images, polices, vidéos, accordéons et contenus chargés après le premier affichage.
• Testez les tailles d’écran prévues ; une page statique peut charger correctement tout en se dégradant à un breakpoint.
• Passez chaque ligne de l’inventaire : formulaire, panier, connexion, recherche, calendrier, analytics et liens de campagne.
• Vérifiez titre de page, description, image sociale et redirections avant de demander aux moteurs ou aux visiteurs d’utiliser la nouvelle adresse.

Les liens cassés et les scripts tiers méritent une attention particulière. Un lien peut être valide à la racine mais échouer depuis une page imbriquée ; un script peut charger sans exécuter sa fonction attendue. Documentez le résultat avec une capture, une URL et une date. Cette rigueur est proche de celle utilisée pour diagnostiquer un flux Etsy vers Meta qui ne se met plus à jour : on suit une entrée, une sortie et une preuve plutôt que de se fier à une impression générale.

Choisir le bon statut pour chaque service

À la fin des tests, attribuez un statut simple à chaque ligne :

• Conservé : la fonction est opérante sur le nouvel hébergement.
• Remplacé : la page ou le bouton renvoie clairement vers le nouveau service.
• Retiré : l’élément n’est plus montré afin d’éviter une promesse trompeuse.
• En attente : la bascule de domaine doit attendre sa résolution.

C’est souvent le meilleur moment pour choisir l’hébergement. ExFlow peut livrer un ZIP ou déployer vers Git, S3, FTP ou son propre hébergement ; le choix dépend du niveau de contrôle attendu, des personnes qui maintiendront le site et du besoin de versionner chaque export. ExFlow propose aussi des exporteurs dédiés à Webflow et à Framer, mais chaque plateforme demande le même inventaire de ses fonctions non statiques.

Une bascule qui reste réversible

Conservez la copie exportée, le tableau de services, les preuves de test et la carte des redirections dans le même dossier de livraison. Avant de modifier le domaine, définissez aussi un retour arrière : qui remet l’ancienne destination, quelle URL de test reste disponible et quel service critique doit être observé après publication. Pour les équipes qui publient fréquemment, une fiche de contrôle pour réviser un post X offre une idée transférable : dater les preuves plutôt que d’espérer se souvenir de la dernière configuration.

La prochaine action est simple : ouvrez le site Squarespace dans un navigateur, listez ses actions qui envoient, recherchent, paient, connectent ou réservent, puis faites un export de test avec ExFlow. Une copie statique devient réellement portable quand chaque service actif a une décision visible et vérifiée.