![\"\"](\"https:\/\/4eck-media.de\/wp-content\/uploads\/2026\/07\/website-checkliste-vor-go-live-qualitaet-statt-pfusch-cover.avif\")
<\/figure>Pour le client, à un tel moment, le site n’est pas terminé à 95 %. Il est cassé. Il ne fait pas la différence entre design, frontend, hébergement et gestion des contenus. Il voit un site web, et chaque erreur porte le logo de son entreprise.<\/p>
C’est pourquoi nous publions ici notre checklist interne complète pour la période précédant le go-live. Ce n’est pas un savoir secret, et c’est précisément le point : la différence entre un site professionnel et un projet du dimanche tient rarement au talent. Elle tient à la discipline. Chez nous, dans l’agence, il n’y a pas de « ça ira » ni de « ça a l’air bien ». Un point est traité ou il ne l’est pas. Entre les deux, il n’y a rien.<\/p>
Cet article traite de tout ce qui est vérifié avant la publication. Pour la période qui suit, il existe une deuxième liste et un article dédié aux vérifications après le go-live<\/a>, car un site en ligne est encore loin d’être terminé. Les deux parties prolongent et approfondissent ce que Matthias a commencé en 2023 dans notre grande checklist de refonte pour boutiques en ligne, sites de réservation et sites corporate<\/a>.<\/p> Les sites web sont construits sur de grands écrans calmes et utilisés sur de petits appareils agités. C’est le problème de fond de presque chaque validation de design. La maquette a été présentée et validée sur 27 pouces. Le visiteur, lui, arrive avec un smartphone vieux de trois ans, le tient d’une seule main et dispose d’une demi-minute de patience.<\/p> C’est pourquoi nous contrôlons chaque projet sur quatre catégories d’appareils, et pas seulement la page d’accueil. Pages de prestations, articles de blog, formulaires, pages de listing, et pour les boutiques la fiche produit et le tunnel de commande : chaque template a ses propres points de rupture. Ne contrôler que la page d’accueil n’est pas un contrôle de site web. C’est un contrôle de page d’accueil.<\/p> Sur les grands écrans, je surveille les lignes de texte trop longues, les contenus perdus dans d’immenses surfaces blanches et les conteneurs qui s’étirent sans largeur maximale. Une mise en page équilibrée sur 1 440 pixels peut se déliter sur un écran de 27 pouces.<\/p> L’ordinateur portable n’est pas pour autant un desktop miniature. Sur 13 à 15 pouces, c’est la hauteur qui pose vraiment problème : la barre du navigateur et le système d’exploitation prennent de la place, et un hero élégant sur un grand moniteur occupe la totalité de la zone visible sur un portable. Je vérifie donc le premier écran comme le ferait un visiteur : comprend-on immédiatement de quoi il s’agit ? Le bouton le plus important est-il accessible, ou est-il masqué par la bannière de cookies et le sticky header ? Voit-on seulement que la page continue plus bas ?<\/p> Dans beaucoup de projets, les tablettes sont testées en dernier. Le desktop est important, le mobile est important, et entre les deux, ça passera bien. C’est précisément là que naissent les erreurs les plus laides : une tablette est assez large pour activer les règles du desktop, mais trop étroite pour en accueillir proprement les contenus. Deux colonnes se retrouvent comprimées, la navigation ne tient plus tout à fait sur une ligne, les images perdent leur point focal.<\/p> Notre liste retient pour cela l’iPad mini et l’iPad Pro, non par amour de la marque, mais parce que nous avons besoin de deux classes de tailles nettement différentes et de conditions de test reproductibles. Et je fais délibérément pivoter l’appareil : un iPad Pro en paysage est presque un ordinateur portable. Le même iPad en portrait impose des contraintes totalement différentes au hero, aux tableaux et aux rangées de cartes.<\/p> Sur le téléphone, un site web s’utilise avec le pouce, sous la pression du temps, souvent en déplacement. Empiler simplement une mise en page desktop ne suffit pas. Les contenus doivent être hiérarchisés, les boutons ont besoin de véritables zones tactiles, les formulaires doivent ouvrir le bon clavier, les numéros de téléphone doivent pouvoir être touchés du doigt. Nous prenons comme référence l’iPhone 12 et l’iPhone 14 Pro, plus des viewports simulés dans le navigateur. Les appareils réels restent malgré tout obligatoires, car aucune simulation ne reproduit entièrement les barres de navigateur, le comportement tactile et les performances réelles.<\/p> Un seul élément à largeur fixe rend toute la page déplaçable horizontalement. Une pop-up dont la croix de fermeture se trouve hors de l’écran bloque complètement le visiteur. Et la question du test n’est jamais seulement « tout est-il visible ? », mais : l’essentiel arrive-t-il assez tôt ? Atteint-on le lien sans toucher celui d’à côté ? Le message d’erreur apparaît-il au niveau du champ concerné ou quelque part en dehors de la zone visible ? Beaucoup de problèmes de qualité ne sont pas assez spectaculaires pour un rapport de bug. Ils créent simplement des frictions, et dans Analytics on ne voit ensuite qu’un taux de conversion plus faible.<\/p> J’adore nos designers. Vraiment. Mais une image occupant toute la largeur de l’écran est presque toujours un compromis technique et régulièrement un petit combat. Dans la maquette, le hero s’inscrit parfaitement dans sa surface fixe. Dans le navigateur, cette surface n’existe pas : un visiteur tient une tablette en portrait, le suivant est assis devant un écran ultra-large, et tous deux doivent voir le même visage, le même produit, la même ligne au bon endroit.<\/p> Techniquement, nous résolvons cela avec plusieurs tailles d’image : notre thème travaille avec six paliers de mise en page, une base mobile et les largeurs à partir de 576, 768, 992, 1 200 et 1 710 pixels. Via srcset et sizes, le navigateur choisit la variante AVIF adaptée au lieu de charger partout l’original le plus grand. Le poids du fichier est ainsi réglé. La composition de l’image, non : avec object-fit, la surface est remplie, mais quelque chose est toujours coupé. Avec object-position, je détermine quelle zone survit. Cela ne fonctionne que si je regarde vraiment le motif dans plusieurs rapports d’aspect.<\/p> S’y ajoute une conversation que j’ai régulièrement : « Nous vous avons pourtant envoyé du matériel haute résolution. » Il s’agit en réalité de Full HD. 1 920 sur 1 080 pixels, cela paraît grand, mais c’est tout simplement insuffisant pour une image pleine surface sur un grand écran Retina, et s’il faut encore choisir un cadrage, il reste encore moins de pixels réels pour la surface visible. Le résultat est un hero net sur l’ordinateur portable et flou sur le grand moniteur. Bien sûr, l’IA peut agrandir. Cela sauve certains motifs, mais invente des détails : les cheveux, les mains, le texte et les façades sont des zones à problèmes typiques. Si le matériel ne fournit pas la résolution nécessaire, je ne promets pas de magie : nous changeons alors le cadrage, la surface ou le type de hero. Ce n’est pas une défaite du design. C’est une décision honnête.<\/p> Pour un seul hero difficile, on arrive vite à 30 minutes au total : vérifier le fichier, générer les variantes, définir le point focal, faire pivoter la tablette, tester l’ultra-large, corriger le contraste, réexporter. Cette demi-heure, personne ne la voit ensuite. Quand elle manque, tout le monde le voit.<\/p> Chaque développeur a un navigateur préféré, et c’est le plus souvent celui dans lequel il développe. C’est normal. Cela devient problématique quand ce même navigateur constitue en même temps l’unique contrôle qualité. Chrome, Firefox, Safari et Edge parlent aujourd’hui largement les mêmes standards, mais pas dans le moindre détail : les polices sont rendues différemment, les champs de formulaire n’ont pas la même apparence, les éléments sticky réagissent différemment dans les cas limites, et Safari cultive ses particularités historiques.<\/p> Notre checklist mentionne donc explicitement les quatre navigateurs, et nous contrôlons les composants présentant le plus grand risque d’erreur : navigation, menus déroulants, sliders, vidéo, bannière de cookies, formulaires, accordéons, onglets, fenêtres modales, éléments sticky, animations. Nous testons Safari sur un véritable appareil Apple : une simulation Chromium ne remplace pas le moteur WebKit. Trouvailles typiques : une police qui ne se charge pas et décale toutes les césures ; une vidéo qui reste figée à cause des règles de lecture automatique ; un état de focus qui disparaît.<\/p> Nous n’essayons pas pour autant de servir chaque version de navigateur des dix dernières années ; ce qui est pertinent est défini avant le début du projet. Mais ne tout simplement pas ouvrir les navigateurs actuellement répandus n’est pas une décision technique. C’est de l’espoir.<\/p> Les mots composés allemands sont brutaux pour les écrans étroits. « Suchmaschinenoptimierungsstrategie » ou « Barrierefreiheitsstärkungsgesetz » font exploser des mises en page entières. La césure automatique en CSS aide, mais dépend du navigateur, de la langue et du dictionnaire. Elle n’est pas partout aussi fiable. C’est pourquoi nous plaçons à la main des points de césure conditionnels dans les titres critiques : le caractère invisible . Tant qu’il y a de la place, on ne voit rien. Si le navigateur doit couper, il le fait au bon endroit et affiche un trait d’union.<\/p> Pourquoi cet effort ? Parce que cette erreur a une propriété particulière : elle n’apparaît jamais sur mon appareil de test. Elle attend le seul client avec la seule largeur d’écran et la police système agrandie, et arrive ensuite la capture d’écran accompagnée de l’aimable question de savoir où nous avions bien pu regarder. Avec des titres allemands longs, « ça finira bien par passer à la ligne » n’est pas une procédure de test.<\/p> Un site web peut être graphiquement excellent et démarrer malgré tout en vol à l’aveugle sur le plan juridique. Avant le go-live, les mentions légales et la politique de confidentialité doivent être créées, liées et accessibles depuis chaque page, et les liens ne doivent surtout pas être masqués par la bannière de cookies. Il faut y ajouter la page de déclaration d’accessibilité, que nous créons pour chaque projet : elle documente le niveau atteint par le site et a sa place dans le pied de page, au même titre que les mentions légales et la politique de confidentialité.<\/p> Unsere Webdesign Agentur<\/a> plant solche Auftritte vom Informationskonzept bis zur performanten Umsetzung.<\/p> L’honnêteté sur les responsabilités est ici essentielle : nous construisons la base technique, intégrons les textes fournis et vérifions les liens. Nous ne remplaçons pas la validation juridique des textes légaux. Et le texte relatif à la protection des données doit correspondre au site réel : analytics, vidéos externes, cartes, newsletter, captcha, ce qui est effectivement intégré doit aussi être décrit. Un texte portant sur un site standard théorique n’aide pas si le site en production présente d’autres flux de données.<\/p> Et puis il y a le favicon, le plus petit point de la liste et le plus fidèlement oublié. S’il manque, l’onglet affiche une icône générique ou celle de l’environnement de développement : rien n’est cassé pour autant, mais cela fait quand même inachevé. Je vérifie l’onglet, les favoris et l’affichage mobile. Et le motif doit survivre à la réduction : un lettrage fin n’est plus qu’une tache en 16 sur 16 pixels.<\/p> L’accessibilité commence dans le design (contrastes, tailles de police, états de focus, structure logique) et ne s’y arrête pas. Pendant le développement et la gestion des contenus, de nouveaux problèmes apparaissent : un rédacteur téléverse une image sans texte alternatif, un titre saute des niveaux, un formulaire reçoit un libellé ambigu. C’est pourquoi nous effectuons avant le go-live un nouveau contrôle automatisé (notre liste mentionne AccessibilityChecker et AccessScan) et complétons les scanners par des vérifications manuelles par sondage.<\/p> Car un scanner peut mesurer si un texte alternatif existe. Il ne sait pas s’il décrit l’image de manière pertinente. Je navigue donc moi-même sans souris dans la navigation, les formulaires et les boîtes de dialogue, je suis le focus visible, je vérifie la hiérarchie des titres et je provoque des erreurs de formulaire : le message apparaît-il au niveau du champ, et le comprend-on ? La page reste-t-elle utilisable en cas de zoom et de police agrandie ?<\/p> Depuis la loi allemande sur le renforcement de l’accessibilité (Barrierefreiheitsstärkungsgesetz) du 28 juin 2025, c’est aussi une question juridique pour de nombreuses offres. Les obligations concrètes dépendent de l’entreprise et doivent, en cas de doute, être clarifiées sur le plan juridique. Ma position pratique en est indépendante : l’accessibilité fait aujourd’hui partie du développement web professionnel au même titre que le HTTPS. Ce n’est d’ailleurs pas un facteur de classement Google général, mais beaucoup de ce qu’elle exige (structure propre, utilisabilité mobile, contenus compréhensibles) profite aussi aux moteurs de recherche et à la conversion. Si vous souhaitez aborder le sujet sérieusement, vous trouverez notre approche sous sites web accessibles<\/a>.<\/p> Unsere SEO Agentur<\/a> betrachtet dabei Technik, Suchintention und Content als zusammenhängendes System.<\/p> Avant qu’un visiteur ne voie le site web, il n’en voit souvent que l’aperçu : sous forme de lien partagé dans WhatsApp, LinkedIn, Slack ou Teams. Cet aperçu est construit par les données Open Graph : og:title, og:description et surtout og:image. Si elles ne sont pas renseignées, la messagerie tire une image quelconque de la page, coupe le titre ou n’affiche tout simplement rien. La première impression du nouveau site est alors un cadre gris.<\/p> Avant le go-live, je vérifie donc pour chaque template : une image d’aperçu est-elle définie, a-t-elle la bonne taille (1 200 sur 630 pixels en standard), montre-t-elle ce qu’il faut, et le titre et la description sont-ils corrects ? Particulièrement important après une refonte : les URL OG ne doivent plus pointer vers le domaine de développement. Le test est simple : jeter le lien dans une messagerie ou un outil d’aperçu et regarder ce qui apparaît réellement. Cela prend quelques minutes et détermine l’allure de chaque recommandation partagée du site.<\/p> Avec les données structurées, nous décrivons le site web de telle sorte que les machines ne voient pas seulement des mots, mais des relations : « 4eck Media » n’est alors plus une suite de caractères, mais une organisation avec une adresse, des prestations, des personnes et des avis. L’approche minimale répandue (installer un plugin SEO, déposer un logo, terminé) produit une ossature de base. Nous allons nettement plus loin et modélisons le site réel : organisation, fondateurs, collaborateurs, catalogues de prestations, articles avec auteur et date, fils d’Ariane, FAQ. Non pas avec des données inventées, mais avec des données vérifiables.<\/p> C’est précisément dans le contexte de la recherche par IA que cela paie : des systèmes comme ChatGPT, Gemini ou Perplexity doivent pouvoir attribuer sans ambiguïté entreprises, personnes et prestations. Les données structurées ne garantissent aucune recommandation. Elles réduisent l’ambiguïté. Avant le go-live, je valide avec le validateur Schema.org et, là où Google prend en charge un type, avec le test des résultats enrichis. Vient ensuite le contrôle qu’aucun validateur ne prend en charge : la confrontation avec la réalité. Si le pied de page indique un numéro de téléphone différent de celui du balisage, le code est techniquement valide et factuellement faux. Le balisage n’est en outre pas un code décoratif posé une fois pour toutes : si l’adresse, l’équipe ou les prestations changent, le niveau lisible par les machines doit suivre, sinon il finit par produire des informations obsolètes particulièrement précises.<\/p> PageSpeed est le point sur lequel je négocie difficilement. Chez nous, un nouveau site démarre dans le vert : au moins 90 points dans Google PageSpeed Insights, l’objectif visé étant 94, 95 et plus. Non pas parce qu’un monde sépare 93 de 95, mais parce que nous avons besoin de réserve. Après la livraison, le site continue de vivre : le client téléverse un jour une photo de 12 mégaoctets, intègre une vidéo, ajoute un script marketing. Qui démarre à exactement 90 passe au jaune dès la première modification imprudente. Qui démarre à 95 encaisse le quotidien.<\/p> Je mesure le mobile et le desktop séparément, et le mobile est le test le plus honnête : processeur plus faible, réseau moins bon, images plus grandes. Derrière le score, je regarde les Core Web Vitals : le LCP (quand le plus grand élément est-il visible ? Le plus souvent, c’est justement l’image hero évoquée plus haut), l’INP (à quelle vitesse la page réagit-elle ?) et le CLS (la mise en page saute-t-elle au chargement ?). Un score de 100 avec un affichage cassé ne vaut rien, mais la phrase inverse, « PageSpeed n’est qu’un outil », ne vaut pas non plus chez moi : l’outil montre des risques réels. Les grands classiques sont presque toujours les mêmes : images trop lourdes, JavaScript bloquant, polices chargées tardivement, scripts tiers. La façon dont nous abordons cela de manière systématique figure sur notre page consacrée à l’optimisation PageSpeed<\/a>.<\/p> Avant le go-live, nous contrôlons les réglages de base de Yoast et faisons en plus crawler l’intégralité du site web. Nous utilisons Seobility pour cela. Le crawler répond à une question à laquelle aucun humain ne peut répondre à l’œil nu : y a-t-il quelque part une page qui sort du rang ?<\/p> Un exemple tiré d’un de nos derniers projets : la rubrique « Technique et méta » était à 98 %. Cela sonne comme terminé. Les deux pour cent manquants correspondaient à deux méta-descriptions problématiques, une anomalie de titre et trois attributs alt absents : exactement la poignée d’erreurs concrètes pour lesquelles ce contrôle existe. Un score global élevé n’est pas une raison d’ignorer le reste de la liste. C’est la raison pour laquelle cette liste est courte.<\/p> Dans Yoast, je vérifie en outre les modèles : un seul article bien renseigné ne prouve rien si un type de contenu personnalisé entier est par mégarde en noindex ou génère automatiquement des titres inutilisables. Et dans le crawl, je fais attention à la structure : des pages importantes enterrées à cinq clics de profondeur ; des textes de lien comme « en savoir plus » qui n’indiquent à personne où ils mènent ; des pages orphelines. Un outil mesure des chemins. C’est un humain qui décide si ces chemins ont du sens. Pour aller plus loin : le grand tour d’horizon, c’est l’audit SEO<\/a> ; avant le go-live, il s’agit des erreurs évidentes qu’il est encore peu coûteux de corriger maintenant.<\/p> Le formulaire de contact est l’endroit où un test apparemment réussi est le plus dangereux. Le développeur le remplit, voit le message de succès vert, coche la case. Une seule chose est ainsi prouvée : le frontend a accepté la demande. Savoir si un e-mail est bien arrivé dans la bonne boîte de réception, si la confirmation est partie vers l’expéditeur, si les données ont été enregistrées : tout cela reste ouvert. Nous avons connu le cas dans la pratique : formulaire vert, boîte de réception vide. Le client ne s’en aperçoit que lorsqu’il s’étonne que plus personne ne le contacte depuis deux semaines.<\/p> Je teste donc le parcours complet : les champs obligatoires doivent fonctionner, les saisies non valides être interceptées de façon compréhensible, le message doit arriver dans la boîte de réception prévue (et non dans les spams), et le nom de l’expéditeur, l’objet, le Reply-To et tous les champs doivent être mis en forme de manière cohérente. Pour une délivrabilité fiable, nous mettons en place une voie SMTP ou un service de mails transactionnels ; SPF, DKIM et DMARC se situent en partie en dehors de WordPress, mais déterminent aussi si le message est jugé digne de confiance. Les formulaires critiques pour l’activité, je les teste avec plusieurs adresses et sur le téléphone. Et la protection anti-spam est préparée, mais elle ne doit pas bloquer de vraies personnes. Le réglage fin suit après le lancement.<\/p> Pour un nouveau domaine sans prédécesseur, ce point est mineur. Lors d’une refonte, le plan de redirections est l’un des documents les plus importants du projet : chaque ancienne URL pertinente reçoit une nouvelle destination cohérente, non pas la page d’accueil par défaut, mais le remplacement le plus proche sur le fond. Je collecte les anciennes URL dans le sitemap, les statistiques, la Search Console et le crawl, nous attribuons les destinations et marquons ce qui disparaît volontairement.<\/p> Les chaînes et les boucles sont dangereuses : si A pointe vers B et B ensuite vers C, cela crée des détours inutiles ; mieux vaut faire pointer A directement vers C. Une boucle rend la destination totalement inaccessible. Le plan est préparé avant le go-live ; il est testé définitivement sur le domaine de production. Nous prenons ainsi les décisions au calme et non au moment où l’ancien site est déjà coupé.<\/p> Avant le go-live, nous amenons WordPress, le thème et les extensions à un état cohérent et à jour, mais pas cinq minutes avant la fin de la journée et jamais sans point de restauration. Les mises à jour modifient du code ; elles comblent des failles et peuvent tout aussi bien introduire de nouveaux conflits. Donc : sauvegarde, mise à jour dans l’environnement de développement, répétition des tests critiques. Le nettoyage est tout aussi important : les extensions de test, les imports de démonstration et les thèmes inutilisés dégagent. Le meilleur nombre d’extensions n’est pas zéro, mais le plus petit nombre qui remplit de manière fiable les tâches convenues.<\/p> Notre liste prévoit en outre de faire passer le chemin de connexion de \/wp-login à un chemin propre au projet. Cela tient à distance le bruit de fond automatisé et n’est expressément pas un concept de sécurité. Une connexion cachée avec le mot de passe « admin123 » n’est pas sûre. Des mots de passe forts, l’authentification à deux facteurs, la limitation des tentatives de connexion et des droits minimaux restent la véritable protection ; les comptes de test sont supprimés avant le lancement.<\/p> Et lors de chaque refonte, nous prenons des captures d’écran de l’ancien site : page d’accueil, pages importantes, navigation, formulaires. Cela sonne nostalgique et constitue une protection très concrète : après la bascule, l’ancien état a disparu, et sinon commence la discussion de mémoire : ce texte était-il déjà ainsi avant ? Cette mention existait-elle ? Une comparaison avant-après répond à ce genre de questions en quelques secondes.<\/p> Sur un site web multilingue, il ne suffit pas de contrôler la version allemande et de faire confiance à l’extension de traduction. Les textes n’ont pas la même longueur : un bouton allemand concis devient large en français, un titre anglais tient sur une ligne, le polonais en demande trois. Les menus, les formulaires, les champs SEO et les textes alternatifs peuvent présenter des lacunes propres à chaque langue. Je traite donc chaque langue comme un site web à part entière : navigation, sélecteur de langue, pages centrales, formulaires, métadonnées, hreflang.<\/p> Un seul bouton en allemand dans un parcours de demande en anglais suffit pour que le visiteur comprenne : ici, le travail n’a pas été mené à son terme. Et la leçon la plus importante tirée de notre propre pratique : le statut « complet » dans l’outil de traduction n’est pas une preuve ; nous avons vu des champs marqués comme traduits et pourtant vides. La façon dont nous traduisons aujourd’hui de grands sites web avec XLIFF et l’IA tout en nous contrôlant nous-mêmes est décrite dans le guide complet de la traduction WordPress avec l’IA<\/a>.<\/p>\n
Un design, quatre vérités : desktop, ordinateur portable, tablette, smartphone<\/h2>
![\"Webdesign](\"https:\/\/4eck-media.de\/wp-content\/uploads\/2026\/07\/responsive-webdesign-bolzakademie-tablet-smartphone-startseite.avif\")
<\/figure>Desktop et ordinateur portable : le premier écran décide<\/h3>
Tablette : l’entre-deux inconfortable<\/h3>
Smartphone : pas plus étroit, mais différent<\/h3>
Images hero : la demi-heure que personne ne voit dans le devis<\/h2>
\n
Test des navigateurs : Chrome seul ne vaut pas validation<\/h2>
Titres longs et : l’erreur qui apparaîtra à coup sûr chez le client<\/h2>
![\"Affichage](\"https:\/\/4eck-media.de\/wp-content\/uploads\/2026\/07\/exec-c87f6807-ca83-4308-bb28-8c5279f93b3f.avif\")
<\/figure>![\"Graphique](\"https:\/\/4eck-media.de\/wp-content\/uploads\/2026\/07\/soft-hyphen-long-headlines-mobile.avif\")
<\/figure>Mentions légales, protection des données, déclaration d’accessibilité et favicon<\/h2>
Accessibilité : la validation du design ne suffit pas<\/h2>
![\"Audit](\"https:\/\/4eck-media.de\/wp-content\/uploads\/2026\/07\/barrierefreiheit-wcag-audit-website-bolzakademie-rostock.avif\")
<\/figure>Données OG : la première impression naît souvent dans WhatsApp<\/h2>
![\"Graphique](\"https:\/\/4eck-media.de\/wp-content\/uploads\/2026\/07\/og-data-link-preview-messenger.avif\")
<\/figure>![\"Contrôle](\"https:\/\/4eck-media.de\/wp-content\/uploads\/2026\/07\/og-image-seo-monitor-mockup-16x9-1-e1784893939736.avif\")
<\/figure>Données structurées : le mode d’emploi destiné aux machines<\/h2>
\n
PageSpeed : 90 est le seuil minimal, pas l’objectif<\/h2>
![\"Rapport](\"https:\/\/4eck-media.de\/wp-content\/uploads\/2026\/07\/pagespeed-optimierung-ladezeit-website-bolzakademie-rostock.avif\")
<\/figure>Yoast et Seobility : les outils trouvent ce que l’œil ne voit pas<\/h2>
![\"Analyse](\"https:\/\/4eck-media.de\/wp-content\/uploads\/2026\/07\/seo-onpage-optimierung-analyse-website-bolzakademie.avif\")
<\/figure>Formulaires et e-mails : envoyer n’est pas encore délivrer<\/h2>
Plan de redirections : planifier avant la refonte, ne pas improviser après<\/h2>
![\"Schéma :](\"https:\/\/4eck-media.de\/wp-content\/uploads\/2026\/07\/redirect-chains-loops-diagram.avif\")
<\/figure>Mises à jour, nettoyage, chemin de connexion et photos de preuve<\/h2>
Traductions : chaque langue est un site web à part entière<\/h2>