DEV Community: Lyode freelance

Site WordPress en panne ou piraté, la procédure que je suis pour diagnostiquer

Lyode freelance — Sun, 14 Jun 2026 23:04:37 +0000

Votre site WordPress ne répond plus. Écran blanc, message d'erreur, ou pire : des liens vers des pharmacies en ligne qui apparaissent dans Google à votre place. La première réaction est de paniquer et de cliquer partout. C'est exactement ce qu'il ne faut pas faire.

Je suis Sébastien, développeur WordPress freelance à Lyon. J'interviens régulièrement sur des sites cassés ou compromis, et dans 90 % des cas, le problème se règle avec une procédure méthodique. Voici celle que je suis, étape par étape.

Deux scénarios très différents se cachent derrière "mon site ne marche plus" :

La panne technique : le site affiche une erreur mais personne n'est entré. Souvent une mise à jour, une extension, un fichier corrompu.
Le piratage : quelqu'un a injecté du code, créé des pages, ou pris la main. Là, ce n'est plus du dépannage, c'est de la sécurité. On va traiter les deux. Mais d'abord, une règle commune.

Avant tout : ne supprimez rien

Le réflexe de tout effacer pour "repartir propre" est la pire idée. Vous détruisez les preuves, et si c'est un piratage, vous risquez de garder la faille tout en perdant les traces qui permettent de la trouver.

Première action, toujours : faites une sauvegarde de l'état actuel, même cassé. Fichiers et base de données. Via votre hébergeur, FTP, ou en ligne de commande si vous y avez accès :

# Sauvegarde de la base de données
mysqldump -u UTILISATEUR -p NOM_DE_LA_BASE > backup-avant-intervention.sql

# Archive des fichiers
tar -czf backup-fichiers.tar.gz /chemin/vers/votre/site

Maintenant, on diagnostique.

Cas 1 : le site est en panne

1. Est-ce votre site, ou tout l'hébergement ?

Avant de plonger dans WordPress, éliminez le plus simple. Si c'est l'hébergeur qui est down, vous allez chercher un bug pour rien.

Testez un autre site hébergé au même endroit, s'il y en a un.
Vérifiez la page de statut de votre hébergeur (la plupart en ont une).
Tapez votre nom de domaine dans un outil comme downforeveryoneorjustme.com pour voir si c'est vous ou tout le monde. Si tout l'hébergement est par terre, contactez le support et passez votre tour. Sinon, on continue.

2. Identifiez le symptôme exact

Le message d'erreur est votre meilleur ami. Notez précisément ce que vous voyez :

Symptôme	Piste la plus probable
Écran totalement blanc	Erreur PHP fatale, conflit d'extension ou mémoire
Erreur 500	Fichier `.htaccess`, PHP, ou extension qui plante
"Erreur de connexion à la base de données"	Identifiants DB, serveur MySQL, table corrompue
Erreur 403	Permissions de fichiers ou règle de sécurité
Site bloqué en "maintenance"	Fichier `.maintenance` laissé après une mise à jour ratée

Ce dernier cas est le plus rapide à régler : connectez-vous en FTP, supprimez le fichier .maintenance à la racine du site, et c'est réglé.

3. Activez le mode debug

Par défaut, WordPress masque les erreurs aux visiteurs. Pour voir ce qui se passe réellement, ouvrez le fichier wp-config.php (à la racine, via FTP) et ajoutez ces lignes avant la ligne /* That's all, stop editing! */ :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );     // écrit les erreurs dans un fichier
define( 'WP_DEBUG_DISPLAY', false ); // ne les affiche pas aux visiteurs

Rechargez le site. Les erreurs s'écrivent maintenant dans wp-content/debug.log. Ouvrez-le : la dernière ligne pointe presque toujours vers le fichier ou l'extension fautive.

Pensez à remettre WP_DEBUG sur false une fois le problème réglé. On ne laisse jamais le debug actif en production.

4. Désactivez les extensions sans accès à l'admin

Si l'admin est inaccessible, vous ne pouvez pas désactiver les extensions depuis le tableau de bord. Passez par le FTP.

Renommez le dossier complet des extensions :

wp-content/plugins  →  wp-content/plugins-off

Votre site se recharge sans aucune extension. S'il revient à la vie, c'est une extension le coupable. Renommez le dossier à l'identique (plugins), puis réactivez les extensions une par une dans l'admin jusqu'à retrouver celle qui casse tout.

5. Repassez sur un thème par défaut

Même logique pour le thème. Renommez le dossier de votre thème actif dans wp-content/themes/. WordPress bascule automatiquement sur un thème par défaut (Twenty Twenty-Four ou similaire). Si le site repart, le problème vient de votre thème, souvent du fichier functions.php.

6. "Erreur de connexion à la base de données"

Ce message a trois causes classiques :

Identifiants incorrects dans wp-config.php (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST). Vérifiez-les auprès de votre hébergeur, surtout après une migration.
Serveur MySQL injoignable : trop de connexions, serveur surchargé. Côté hébergeur.
Table corrompue. WordPress propose un outil de réparation. Ajoutez dans wp-config.php :

define( 'WP_ALLOW_REPAIR', true );

Puis visitez votre-site.fr/wp-admin/maint/repair.php, lancez la réparation, et retirez la ligne aussitôt après (sinon n'importe qui peut accéder à cet outil).

7. La mémoire PHP est saturée

L'écran blanc vient parfois d'une limite mémoire trop basse, surtout sur les sites un peu lourds. Augmentez-la dans wp-config.php :

define( 'WP_MEMORY_LIMIT', '256M' );

Si ça ne suffit pas, le réglage se fait au niveau de l'hébergement (php.ini ou panneau de l'hébergeur).

Cas 2 : le site est piraté

Ici, la logique change. On ne cherche plus à "réparer", on cherche à nettoyer et sécuriser. Et la règle d'or : tant que vous n'avez pas trouvé par où c'est entré, le site se fera repirater.

Les signes qui ne trompent pas

Des redirections vers des sites inconnus (pharmacie, casino, contrefaçon).
Des pages indexées dans Google que vous n'avez jamais créées.
Google ou votre navigateur affiche un avertissement "site dangereux".
Des comptes administrateurs que vous ne reconnaissez pas.
Des fichiers récemment modifiés alors que vous n'avez touché à rien.
Votre hébergeur vous a envoyé une alerte de sécurité. ## 1. Isolez le site

Mettez le site en mode maintenance (HTTP 503) pour stopper la propagation et éviter que vos visiteurs soient infectés ou redirigés pendant l'intervention. Si l'attaque est grave, demandez à votre hébergeur de couper l'accès public temporairement.

2. Lancez un scan

Installez un scanner reconnu (depuis l'admin, ou en FTP si l'admin est bloqué) :

Wordfence : la référence gratuite, scan approfondi.
MalCare : scan côté serveur, très rapide.
Sucuri : bon pour le scan distant et la blacklist Google. Le scan vous liste les fichiers modifiés, les fichiers inconnus, et les injections suspectes. C'est votre carte du champ de bataille.

3. Traquez les fichiers récemment modifiés

Si vous avez un accès SSH, c'est l'outil le plus efficace. Listez tous les fichiers PHP modifiés ces 7 derniers jours :

find . -type f -name "*.php" -mtime -7 -ls

Et repérez les motifs typiques du code malveillant (code obfusqué, exécution déguisée) :

grep -rEl "eval\(|base64_decode\(|gzinflate\(|str_rot13\(" wp-content/

Ces fonctions ont parfois des usages légitimes, mais combinées et planquées dans wp-content/uploads/, elles sont presque toujours le signe d'une porte dérobée.

4. Remplacez le cœur, ne le réparez pas

N'essayez pas de "nettoyer" les fichiers du cœur de WordPress un par un. Remplacez-les en bloc par les versions officielles. Avec WP-CLI :

# Vérifie quels fichiers du cœur ont été altérés
wp core verify-checksums

# Réinstalle le cœur proprement, sans toucher à vos contenus
wp core download --force --skip-content

Faites pareil pour vos extensions et thèmes : réinstallez-les depuis les sources officielles plutôt que de tenter de les désinfecter.

5. Comptes fantômes, clés et mots de passe

Trois actions non négociables :

Supprimez les comptes administrateurs inconnus. Vérifiez aussi la table wp_users directement, certains pirates créent des admins invisibles dans l'interface.
Régénérez les clés de sécurité (SALT). Récupérez un nouveau jeu sur https://api.wordpress.org/secret-key/1.1/salt/ et remplacez le bloc correspondant dans wp-config.php. Ça déconnecte toutes les sessions actives, y compris celle du pirate.
Changez tous les mots de passe : admin WordPress, base de données, FTP, et compte d'hébergement. ## 6. Nettoyez la base de données

Le code malveillant ne vit pas que dans les fichiers. Inspectez la table wp_options (lignes siteurl, home, scripts injectés), les articles et pages contenant du JavaScript suspect, et les entrées de spam. Un plugin comme Wordfence repère une partie de ces injections, mais une vérification manuelle reste souvent nécessaire.

7. Demandez le réexamen à Google

Si Google a blacklisté votre site, la dernière étape est de demander un réexamen via la Google Search Console, dans la section Sécurité et actions manuelles. À ne faire qu'après un nettoyage complet : si la moindre trace subsiste, Google maintiendra l'avertissement plus longtemps. Le centre de recherche Google propose un guide officiel dédié aux sites piratés, à lire avant la demande.

Quand passer la main

Vous pouvez gérer beaucoup de choses seul avec cette procédure. Mais certains signaux indiquent qu'il vaut mieux ne pas insister :

Vous avez nettoyé, et le piratage revient quelques jours plus tard. La faille est toujours là.
Le site est un e-commerce ou traite des données clients (enjeu RGPD, obligation de déclaration à la CNIL en cas de fuite).
Vous n'avez pas de sauvegarde propre et le nettoyage manuel touche des fichiers que vous ne maîtrisez pas.
Le site est blacklisté et chaque jour hors ligne vous coûte du chiffre d'affaires.
Vous n'êtes simplement pas à l'aise avec le FTP, la base de données ou la ligne de commande, et une erreur peut aggraver la situation. Dans ces cas, un nettoyage approximatif coûte plus cher qu'une intervention propre, parce qu'il laisse une porte ouverte.

J'interviens sur ce type de situation, en dépannage ponctuel comme en suivi régulier. Si vous êtes face à un site cassé ou compromis :

Site piraté : la procédure complète de nettoyage et de sécurisation est détaillée ici 👉 Site WordPress piraté : diagnostic, nettoyage et protection

- Pour éviter d'en arriver là : un contrat de maintenance (mises à jour, sauvegardes, surveillance) règle 90 % de ces incidents en amont 👉 Maintenance WordPress à Lyon

Pour aller plus loin

La meilleure procédure de diagnostic reste celle qu'on n'a jamais à utiliser. La plupart des pannes et piratages que je traite auraient été évités par quelques bons réflexes :

Lyode freelance

Apr 1

WordPress 7.0 Delayed - What It Means for Your Maintenance Strategy

#news #webdev #wordpress #maintenance

4 min read

Post not found or has been removed.

Et vous, quel a été votre pire incident WordPress ? Racontez en commentaire, c'est toujours instructif de comparer les diagnostics.

Sébastien, développeur WordPress freelance à Lyon. J'aide les TPE et PME à construire, optimiser et maintenir des sites fiables. En savoir plus sur lyode.fr.

Maintenance WordPress : les 7 incidents qui auraient pu être évités

Lyode freelance — Wed, 27 May 2026 21:06:44 +0000

Retour d'expérience de freelance WordPress sur les incidents les plus fréquents en clientèle et pourquoi la maintenance n'est jamais un luxe.

Quand un client appelle en panique parce que son site est en carafe, c'est rarement par hasard. Dans 9 cas sur 10, l'incident aurait pu être détecté plusieurs semaines avant, lors d'une intervention de maintenance bien menée.

Je m'appelle Sébastien, je suis développeur WordPress freelance à Lyon, et je gère plusieurs contrats de maintenance en parallèle de projets de création de sites. Voici une liste honnête des incidents que j'ai eus à traiter ces derniers mois, et ce qu'une maintenance régulière aurait changé.

1. La mise à jour de plugin qui casse l'affichage

Classique. Une extension Elementor passe en version majeure, et tout un layout responsive se retrouve cassé sur mobile. Le client ne s'en rend compte que trois jours plus tard, quand un prospect lui signale.

Ce qu'une maintenance bien faite change : les mises à jour passent d'abord par un environnement de staging ou, à défaut, par un site cloné. Avant chaque update, une sauvegarde complète (fichiers + base + config serveur). Si quelque chose casse, on rollback en 5 minutes plutôt qu'en 4 heures de debug.

2. Le plugin abandonné par son auteur

Un plugin populaire en 2022 n'a plus reçu de mise à jour depuis 18 mois. Compatible jusqu'à WordPress 6.3, on est en 6.7. Au prochain update du core, il casse silencieusement une fonctionnalité critique.

La maintenance permet d'auditer régulièrement les extensions actives : dernière mise à jour, compatibilité annoncée, vulnérabilités CVE connues. Quand un plugin commence à dériver, on cherche un remplaçant maintenu avant qu'il devienne un problème.

3. L'attaque brute force sur wp-login.php

Sans monitoring, vous ne le voyez pas. Avec monitoring, vous voyez 4 000 tentatives de connexion en 48h sur un compte admin avec un identifiant deviné depuis l'URL /author/admin/.

Quelques basiques qui changent tout :

Désactiver l'énumération des auteurs (?author=1)
Renommer ou cacher wp-admin derrière un slug custom
Limiter les tentatives de connexion avec un plugin léger
Mettre en place l'authentification à deux facteurs sur les comptes administrateurs

Aucune de ces actions n'est compliquée. Mais aucune ne se fait toute seule.

4. Le certificat SSL qui expire un dimanche soir

Renouvellement automatique mal configuré chez l'hébergeur, certificat Let's Encrypt qui expire un dimanche, site qui passe en "Connexion non sécurisée" sur Chrome pour tous les visiteurs du lundi matin.

Un monitoring qui surveille la date d'expiration du certificat et alerte 15 jours avant règle le problème. C'est dix lignes de configuration, et ça évite une journée d'incident à fort impact business.

5. Le serveur saturé par les images

Quatre ans d'exploitation, jamais de nettoyage. La médiathèque pèse 28 Go. Les images originales en 4000x3000 px sont servies telles quelles. Le score PageSpeed Mobile est passé de 78 à 31 sans que personne ne le remarque.

La performance ne se dégrade pas d'un coup. C'est une dérive lente, invisible au quotidien, qui finit par impacter le SEO et le taux de conversion. Une maintenance régulière inclut un contrôle des optimisations existantes : cache (WP Rocket, W3 Total Cache), compression d'images (Imagify, ShortPixel), minification HTML/CSS/JS, lazy loading.

6. La base de données qui gonfle silencieusement

Révisions de posts non purgées, transients expirés mais jamais nettoyés, tables d'anciens plugins toujours présentes après désinstallation. La base passe de 80 Mo à 1,2 Go en deux ans. Les requêtes ralentissent. Le TTFB grimpe.

Un nettoyage trimestriel — optimisation des tables, purge des révisions au-delà de N versions, suppression des transients expirés — garde la base saine.

7. Le rapport qu'on ne fait jamais

Le plus invisible des problèmes, mais celui qui empoisonne la relation client. Si vous facturez de la maintenance et que vous ne livrez aucune trace écrite de ce qui a été fait, le client doute. Il ne sait pas s'il en a pour son argent. Et il a raison de douter.

Chaque intervention devrait produire un rapport synthétique : mises à jour appliquées (avec versions avant/après), corrections réalisées, anomalies détectées, actions recommandées pour la suite. C'est ce qui transforme la maintenance d'une dépense floue en un service traçable.

Ce que j'ai mis en place

Pour mes propres clients, j'ai structuré la maintenance autour de quatre piliers : sécurité et mises à jour maîtrisées, sauvegardes avec plan de reprise, optimisations continues, et reporting détaillé. Je m'appuie sur un outil de monitoring dédié pour suivre la disponibilité, le temps de réponse, le certificat SSL et les alertes techniques entre deux interventions.

Sur le format, deux options selon le profil du site :

Intervention ponctuelle (150 €, environ une demi-journée) : pour les sites vitrines ou les projets qui n'ont pas besoin d'un suivi mensuel mais qui doivent rester sains.
Contrat mensuel ou trimestriel : pour les sites institutionnels ou e-commerce avec plus d'enjeux, plus de plugins, plus d'exposition.

Si vous êtes basé dans la région lyonnaise et que votre site WordPress tourne sans suivi depuis un moment, le détail de ma prestation est sur lyode.fr — Maintenance WordPress.

En résumé

La maintenance WordPress n'est pas un produit de luxe ni une rente d'agence. C'est juste ce qui fait la différence entre un site qui fonctionne dans cinq ans et un site qui tombe en panne au pire moment. Les sept incidents listés ici ont tous un point commun : ils sont prévisibles, et donc évitables.

Si vous gérez votre site vous-même, vous avez largement de quoi faire avec cette liste. Si vous préférez le confier à quelqu'un dont c'est le métier, c'est aussi une option raisonnable.

WordPress 7.0 Delayed - What It Means for Your Maintenance Strategy

Lyode freelance — Wed, 01 Apr 2026 22:48:01 +0000

WordPress 7.0 was supposed to ship on April 9, 2026. That's no longer happening.
On March 31, Matias Ventura announced on Make WordPress Core that the release is being pushed back by several weeks. No new date has been set yet.
This isn't the first delay in the 7.0 cycle - Beta 1 was already postponed in February due to unit test failures, and RC1 was delayed in March over performance concerns. But this time, the delay is architectural, not just a schedule slip.

What's causing the delay

The core issue is Real-Time Collaboration (RTC) - a feature that introduces live co-editing in the WordPress block editor, similar to what Google Docs offers.
Building this requires a new database table, changes to how WordPress handles editing sessions, and a rethinking of how post caches work during active collaboration. The team realized that the database schema needed more design work before being locked into a major release.
Key concerns raised by contributors:

**Performance: **real-time editing currently disables persistent post caches during active sessions
Database design: the proposed single RTC table tries to serve both real-time editing (high-frequency, low-latency writes) and synchronization (batch operations) - two fundamentally different workloads
Testing gaps: database schema changes increase the risk of failures during upgrades, and the usual testing path via the Gutenberg plugin was rejected because it could affect production sites

The RTC feature will ship as opt-in, giving hosts and site owners time to evaluate the impact before enabling it.

Why this matters for site maintenance

If you manage WordPress sites - whether it's your own or your clients' - this delay has practical implications.

1. Don't rush the update when it drops
When 7.0 finally ships, it will include database migrations. That's a different beast than a typical minor update. Your maintenance checklist should include:

Full database backup before updating (not just files)
Staging environment test - run the update on a staging copy first
Plugin compatibility check - especially for page builders, caching plugins, and any plugin that hooks into the editor
Monitor post-update - watch for slow queries or unexpected behavior in the editor

2. Use this window to get your house in order
The delay gives you extra time to prepare. Here's what to tackle now:

Update to WordPress 6.9.3 if you haven't already - it includes 10 security patches
Audit your plugins - remove anything inactive or unmaintained. Fewer plugins = smoother major upgrades
Check your PHP version - WordPress 7.0 is expected to require PHP 7.4+ at minimum, and PHP 8.1+ is recommended
Review your backup strategy - make sure automated backups include both files AND database, with at least 7 days of retention

3. Plan for the RTC feature decision
Even though RTC will be opt-in, you'll need to decide whether to enable it for each site you manage. Consider:

Do your clients actually need real-time co-editing?
Can your hosting handle the additional database writes?
Are your caching layers compatible with the new collaboration mode?

For most small business sites, the answer is probably "not yet." But for content teams with multiple editors, it could be transformative.

The bigger picture

WordPress powers a massive share of the web. A major version release with database schema changes affects millions of sites simultaneously. The fact that the core team is taking extra time to get the architecture right - rather than shipping on schedule and patching later - is a good sign.
But it also reinforces something I see constantly in my work as a WordPress freelancer in Lyon: maintenance isn't optional, it's infrastructure. Every major WordPress release is a moment where the gap between "sites that are actively maintained" and "sites that are left on autopilot" becomes painfully visible.
Sites with a proper maintenance workflow - regular backups, staging environments, plugin audits, monitoring - will handle the 7.0 transition smoothly. Sites without one will scramble.

What to do right now

Don't install WordPress 7.0 RC builds on production sites - they're for testing only
Set up a staging environment if you don't have one (most hosts offer one-click staging)
Run a full backup and verify you can restore from it
Subscribe to Make WordPress Core for the updated release timeline
Audit your plugin list - anything that hasn't been updated in 12+ months is a risk factor for 7.0 compatibility

The new release date hasn't been announced yet, but it's expected to be "a few weeks" after the original April 9 target. I'll update this post when the timeline is confirmed.

I'm Sébastien, a WordPress developer and SEO specialist based in Lyon, France. I help businesses build, optimize, and maintain their WordPress sites. If you're looking for help preparing for WordPress 7.0 or need ongoing maintenance support, you can find out more about my services here.

Web Project Acceptance Testing: A Practical Guide (with Checklist)

Lyode freelance — Tue, 10 Mar 2026 12:22:46 +0000

Ever launched a website only to discover a broken form, a missing redirect, or a page that looks terrible on mobile — after going live? That's what proper acceptance testing is designed to prevent.

What is Web Acceptance Testing?
Web acceptance testing (called recettage in French project management) is the structured process of validating a website or web application before it goes live. It ensures the final deliverable matches the initial specifications — functionally, technically, and from a user experience standpoint.
It's not just "clicking around to see if things work." It's a documented, step-by-step validation that covers every layer of your project.

The 3 Phases You Shouldn't Skip

Intermediate testing (during development) Run at the end of each sprint or functional phase. Validates features progressively and avoids the "big bang" effect at delivery.
User Acceptance Testing (UAT) Performed by the client or end users. The goal: confirm the product actually meets real business needs — not just technical specs.
Final pre-production testing The last checkpoint before go-live. Everything gets tested one final time: responsiveness, SEO, RGPD compliance, redirects, performance. This phase ends with a sign-off document authorizing production deployment.

Step-by-Step Method
Step 1 — Write your acceptance test plan
Document every feature to test, the expected result, and the validation criteria. Derive it directly from your specifications or backlog.
Step 2 — Build your test scenarios
Each scenario simulates a real user action:

Submit a contact form → verify email received
Add product to cart → complete checkout
Navigate on mobile → check layout and readability

Always include edge cases: empty fields, unauthorized actions, unusual screen sizes.
Step 3 — Run the tests
Each test gets one of three statuses:

✅ Passed
⚠️ Minor issue
❌ Blocking bug

Use a simple tool (Notion, Trello, or even a spreadsheet) to track results.
Step 4 — Track and fix anomalies
Every bug must be documented (screenshot + steps to reproduce), prioritized, assigned, fixed, and retested. Don't skip the retest — fixes sometimes introduce new issues.
Step 5 — Technical & SEO verification
This is where many teams cut corners. Before signing off, verify:

Page load speed (PageSpeed Insights)
Every page returns HTTP 200 (no silent errors)
No broken links or missing redirects
JavaScript console is clean
robots.txt and sitemap are correct

The Acceptance Testing Checklist
FUNCTIONAL
☐ All forms submit correctly and trigger expected emails
☐ Navigation links point to correct pages
☐ Dynamic content loads properly (sliders, filters, search)

RESPONSIVE
☐ Mobile layout is clean and usable
☐ Touch targets are large enough
☐ No content overflow on small screens

TECHNICAL
☐ All pages return HTTP 200
☐ No 404 errors on internal links
☐ 301 redirects are active (after a redesign)
☐ Page speed score is acceptable (Core Web Vitals)
☐ No JS errors in browser console

SECURITY
☐ SSL certificate is valid on all pages
☐ Admin access is protected
☐ Forms are protected against XSS and SQL injection

LEGAL & COMPLIANCE
☐ Cookie consent banner is present
☐ Privacy policy is linked in forms
☐ GDPR data handling is documented

SIGN-OFF
☐ All blocking bugs resolved
☐ Client/stakeholder approval obtained
☐ PV de recette (acceptance report) signed

Common Mistakes to Avoid

Testing only in your local environment, not on a staging server
Skipping mobile testing entirely
Not involving the actual end user in UAT
Forgetting to document anomalies (memory is not a bug tracker)
Treating acceptance testing as a one-time event rather than an iterative process

Going Deeper
If you work in French or with French-speaking clients, I wrote a comprehensive guide on recettage web covering all these phases in detail, including tools and real-world examples: Recettage : définition, étapes et bonnes pratiques
If you need help running acceptance testing on your WordPress project or want a freelance partner for the full delivery process, you can also check out my freelance services at Lyode.

What's your go-to tool for tracking bugs during acceptance testing? Drop it in the comments.

Cleaning a 4,000-image WordPress Media Library without breaking SEO

Lyode freelance — Thu, 29 Jan 2026 12:41:07 +0000

Cleaning a 4,000-image WordPress Media Library without breaking SEO

On most WordPress sites, the media library is the dirtiest part of the stack.

Not the theme.

Not the plugins.

Not even performance.

The media library.

Recently, I had to clean a WordPress site with nearly 4,000 images accumulated over several years. Multiple contributors, no rules, no real process.

The challenge wasn’t “optimizing images”.

It was cleaning everything without breaking SEO or existing content.

This article explains what actually goes wrong, what you should never do, and a safe strategy to clean a large WordPress media library.

Why WordPress media libraries rot over time

Media libraries don’t become messy because people are careless.

They rot because WordPress makes it very easy to upload files — and very hard to enforce rules.

Over time, you usually end up with:

Images named IMG_4839.jpg, final-banner-ok-v3.png, screenshot_2021_12_edited.jpg
Missing or useless ALT attributes
Images uploaded at 4000px wide for a 1200px layout
Useful formats blocked by default (SVG, WEBM, ZIP…)
No consistency between old and new content

Add editors, clients, interns, agencies… and the mess compounds.

The worst part?

Most people are afraid to touch the media library, because they fear breaking pages or SEO.

That fear is justified.

What you should NOT do

Before talking about solutions, let’s be clear about the mistakes.

❌ Manually renaming files

Renaming media files directly (FTP or media replacement) can break:

internal references
external links
cached URLs
social previews

❌ Re-uploading images “cleanly”

Re-uploading means:

losing existing URLs
losing Google Image history
risking broken layouts

❌ Aggressive compression plugins

Compression is not cleaning.

Compression plugins can:

degrade image quality
change file hashes
trigger layout shifts
hide structural issues instead of fixing them

❌ Blind AI-generated ALT text

Automatically generating descriptive ALT text without context:

creates irrelevant descriptions
introduces semantic noise
can hurt accessibility and SEO

Automation is fine.

Guessing is not.

The safe cleanup strategy

When dealing with thousands of images, the goal is normalization, not magic.

Here’s a strategy that works reliably.

1. Normalize filenames (without breaking URLs)

You don’t need poetic filenames.

You need clean, readable, predictable ones.

Remove useless characters (_, random hashes, duplicated words)
Keep meaningful words when possible
Apply the same rules everywhere

Done properly, this improves long-term maintainability without breaking references.

2. Generate clean, neutral ALT attributes

ALT text is not a keyword playground.

For large libraries:

Neutral, descriptive ALT is safer than “creative” ALT
Consistency is more important than cleverness
Missing ALT is worse than simple ALT

The goal is accessibility first, SEO second.

3. Resize images (not compress them)

Most WordPress images are simply too large.

Resizing means:

keeping visual quality
reducing unnecessary pixels
matching real display needs

On large sites, resizing alone can save hundreds of megabytes, without touching compression.

4. Control allowed formats properly

WordPress blocks many useful formats by default.

Instead of hacks:

explicitly allow required formats
apply proper security rules
keep control at upload level

This avoids unsafe plugins and manual workarounds.

Real case: cleaning a 4,000-image media library

On this project, the site contained 3,949 images.

After cleanup:

79 missing ALT attributes were generated
1,150 filenames were normalized
80 oversized images were resized
~370 MB of disk space was saved

No broken pages.

No URL changes.

No SEO loss.

The tool I used (and why I built it)

To automate this safely, I built a small WordPress plugin called Filikod.

Important clarifications:

No AI
No destructive compression
No guessing

Filikod focuses on:

predictable automation
structural cleanup
long-term consistency

You can find it here on WordPress.org:

https://wordpress.org/plugins/filikod/

And the project website:

https://filikod.com

(No hard sell. Just context.)

When automation makes sense (and when it doesn’t)

Automation makes sense when:

the site has hundreds or thousands of images
multiple people upload content
consistency matters over time

Automation is not always necessary for:

very small sites
single-author blogs
temporary projects

The key is control, not speed.

Final thoughts

A messy media library is not a minor issue.

It’s a structural problem that affects:

performance
accessibility
SEO
long-term maintenance

The solution isn’t magic plugins or AI promises.

It’s boring, predictable cleanup, done safely.

Tools should clean.

Not guess.

Filikod : le plugin WP qui prend soin de vos images

Lyode freelance — Thu, 11 Dec 2025 21:23:36 +0000

Gérer les médias d’un site WordPress n’est jamais anodin.
Images trop lourdes, ALT text oubliés, formats refusés… ces petits détails s’accumulent et finissent par impacter les performances, l’accessibilité et le SEO.

Pour aider les utilisateurs à simplifier cette gestion, nous avons créé Filikod, un plugin gratuit dédié à la qualité des images.
https://filikod.com

Qu’est-ce qu’un ALT text et pourquoi est-il important ?

L’ALT text est une description d’image utilisée :

par Google pour comprendre le contenu visuel,
par les lecteurs d’écran pour l’accessibilité,
par les navigateurs si l’image ne peut pas s’afficher.
Un ALT text manquant ou mal renseigné affaiblit le SEO et crée un obstacle pour les utilisateurs en situation de handicap.

Avec Filikod

Le plugin génère automatiquement un ALT text propre lors de l’upload,
et propose un outil permettant de corriger l’intégralité des images déjà présentes dans la médiathèque.

Pourquoi vos images doivent-elles être redimensionnées ?

Une image trop large ralentit le chargement de vos pages et alourdit votre espace de stockage.
La plupart des images envoyées sur WordPress dépassent la largeur réellement nécessaire pour l’affichage.

Avec Filikod

Le plugin peut :

redimensionner automatiquement les nouvelles images,
ajuster les images existantes via un traitement global. Il conserve la qualité, réduit le poids et applique une taille cohérente pour tout le site.

Quels formats supplémentaires peut-on activer ?

WordPress n’autorise pas certains fichiers utiles au quotidien :
PSD, AI, ICO, ZIP, WEBM…
**
Avec Filikod**

Vous pouvez activer ou désactiver ces formats directement depuis le tableau de bord, sans manipulations complexes.

Le contrôle est simple, visuel, et adapté aux besoins de chaque site.

Comment installer Filikod ?

Aller sur WordPress.org : https://wordpress.org/plugins/filikod
Installer le plugin
Activer
Laisser Filikod travailler en arrière-plan

5 bonnes pratiques pour améliorer la performance de votre site WordPress

Lyode freelance — Wed, 29 Oct 2025 20:20:22 +0000

La performance d’un site WordPress n’est pas qu’une question de rapidité : c’est aussi un facteur essentiel pour le référencement naturel (SEO) et l’expérience utilisateur.

En tant que développeur WordPress freelance à Lyon, j’optimise chaque projet pour obtenir un site à la fois fluide, léger et durable.

Voici 5 bonnes pratiques simples à mettre en place 👇

⚙️ 1. Allégez vos plugins

Chaque plugin ajoute du code, parfois inutile. Avant d’en installer un nouveau, demandez-vous s’il est vraiment indispensable.

Supprimez les extensions inactives et privilégiez les solutions légères (ou un petit bout de code sur mesure).

🧠 2. Optimisez vos images

Les images sont souvent les fichiers les plus lourds. Utilisez le format WebP quand c’est possible, activez la compression et le lazy loading.

Des outils comme TinyPNG ou des plugins spécialisés comme filikod ou imagify peuvent vous aider.

🔒 3. Activez la mise en cache

Une extension comme WP Rocket ou LiteSpeed Cache permet de stocker des versions statiques de vos pages pour accélérer le chargement.

C’est souvent la première amélioration visible pour l’utilisateur.

📡 4. Surveillez vos Core Web Vitals

Les métriques comme LCP, FID et CLS sont mesurées par Google et influencent votre positionnement.

Testez régulièrement votre site sur PageSpeed Insights pour détecter les points d’amélioration.

🧰 5. Tenez votre site à jour

WordPress, les thèmes et les plugins doivent être mis à jour pour garantir la stabilité et la sécurité.

Une maintenance régulière évite les lenteurs et les vulnérabilités.

💡 Ces optimisations sont cumulatives : appliquées ensemble, elles améliorent le score Lighthouse et la satisfaction des visiteurs.

📍 Je partage régulièrement des tutoriels WordPress et des conseils sur la performance, la sécurité et le SEO.

👉 Découvrez mon plugin et mes conseils sur Lyode.fr – création et optimisation de sites WordPress