---
title: "Combien de sites WordPress peut-on héberger sur une offre o2switch ?"
description: "(et pourquoi la réponse n’est pas la même que pour les sites statiques)"
url: "https://eclaircms.ludicweb.fr/blog/combien-de-sites-wordpress-peut-on-heberger-sur-une-offre-o2switch"
lang: "fr"
author: "Christophe Marcellin"
published: "2025-05-22"
updated: "2026-11-04"
---

# Combien de sites WordPress peut-on héberger sur une offre o2switch ?

*(et pourquoi la réponse n’est pas la même que pour les sites statiques)*

## 1. Rappel : ce que l’on pouvait faire avec **des sites statiques**

Dans l’article précédent – « [Combien de sites statiques peut‑on héberger sur une offre o2switch ?](https://www.ludicweb.fr/combien-de-sites-statiques-peut%e2%80%91on-heberger-sur-une-offre-o2switch) » – on a montré qu’un simple fichier HTML/CSS ne sollicite quasiment que les **inodes** (le compteur de fichiers).

Avec 500 000 inodes par compte :

| Page statique moyenne | Fichiers | Sites théoriques possibles |
| --- | --- | --- |
| Landing ultra-minimal | ≈ 10 | \~ 50 000 |
| Landing « classique » | ≈ 30 | \~ 16 000 |
| Page riche | ≈ 100 | \~ 5 000 |

CPU, RAM et I/O restaient anecdotiques, d’où la conclusion qu’« on peut déployer plusieurs **milliers** de micro-sites sans broncher ».

## 2. Pourquoi **WordPress** change la donne ?

| Ressource | Impact d’un site **statique** | Impact d’un site **WordPress** |
| --- | --- | --- |
| **Inodes** | 10 – 100 | 2 000 – 10 000 (core + thèmes + plugins + médias) |
| **CPU** | quasi nul | Exécution PHP/MySQL à chaque page non mise en cache |
| **RAM** | ≤ 50 Mo | 128 Mo – 1 Go selon la page et les plugins |
| **I/O disque** | pics rares (déploiement) | écriture régulière (uploads, logs, backups) |

Autrement dit, la question n’est plus « combien de fichiers puis-je stocker ? », mais **combien de secondes CPU et de méga-octets de RAM mes sites consomment-ils en même temps ?**

## 3. Les 3 offres o2switch 2025 côté ressources

| Offre | Threads CPU | RAM | I/O | Inodes | « Lunes » (sous-comptes) |
| --- | --- | --- | --- | --- | --- |
| **Grow** | 8 | 16 Go | 16 MB/s | 500 000 | 4 |
| **Cloud** | 12 | 48 Go | 42 MB/s | 500 000 | 8 |
| **Pro** | 24 | 64 Go | 84 MB/s | 500 000 | 16 |

([o2switch FAQ](https://faq.o2switch.fr/espace-client/offre/comparatif-offre-unique-o2switch/))

## 4. Combien consomme **un** site WordPress ?

| Type de site | Fichiers | CPU moyen† | RAM pic | Visites mensuelles « confort » |
| --- | --- | --- | --- | --- |
| **Vitrine légère** (thème natif, ≤ 5 plugins) | ≈ 2 500 | 0,02 thread | ≤ 128 Mo | ≤ 5 000 |
| **Blog / PME** (Astra + 15 plugins) | ≈ 4 000 | 0,05 thread | 256 – 512 Mo | \~ 20 000 |
| **WooCommerce** (20 plugins, 1 000 produits) | 6 000 – 10 000 | 0,2 thread | 512 Mo – 1 Go | \~ 50 000 |

†*Moyenne lissée sur un mois, cache de page actif.*

## 5. Calcul : combien de sites Wordpress **en même temps** ?

### a) Limite « fichiers » (inodes)

Même si WordPress grossit, l’inode reste rarement le premier verrou :

| Offre | Vitrine | Blog | WooCommerce |
| --- | --- | --- | --- |
| Grow/Cloud/Pro (500 000 inodes) | jusqu’à 200 sites | \~ 120 sites | \~ 60 sites |

Mais vous toucherez **le CPU bien avant** ces chiffres.

### b) Limite CPU/RAM (le vrai goulot)

| Offre | Vitrines (≤ 5 k visites/mois) | Blogs (20 k) | WooCommerce (50 k) |
| --- | --- | --- | --- |
| **Grow** (8 threads) | 30 – 50 | 8 – 15 | 1 – 3 |
| **Cloud** (12 threads) | 50 – 100 | 15 – 30 | 3 – 6 |
| **Pro** (24 threads) | 100 + | 30 – 60 | 6 – 10 |

Ces fourchettes supposent :

- **Cache de page** (PowerBoost, Redis, LiteSpeed LSCache ou plugin type WP Rocket).
- Trafic réparti (pas de spikes simultanés).
- Images optimisées (WebP/CDN), plugins utiles uniquement.

Sans cache ou avec un plugin très lourd, un seul WooCommerce peut monopoliser 1 thread à lui tout seul ; la limite tombe alors à … 1 site !

## 6. Mise en perspective sites statiques VS Wordpress

| Question | Sites **statiques** | Sites **WordPress** |
| --- | --- | --- |
| Ressource qui bloque en 1ᵉʳ | Inodes | CPU / RAM |
| Nombre possible sur Grow | **5 000 – 50 000** pages mono-HTML | **30 – 50** sites WP |
| Impact d’un CDN | Confortable mais non vital | Quasi indispensable pour les gros sites |
| Maintenance | Push de fichiers | Mises à jour core + thèmes + plugins, sécurité, optimisation DB |

Le même serveur mutualisé capable d’abriter des **milliers** de petites landing pages statiques devra être mis à niveau (ou optimisé) après **quelques dizaines** de WordPress.

## 7. Conseils pour héberger « beaucoup » de WordPress

1. **Activez le cache dès l’installation.** PowerBoost dans cPanel ou Redis + LSCache font des miracles.
2. **Surveillez “Statistiques → Utilisation CPU”** dans cPanel ; si la barre dépasse 80 % plusieurs heures d’affilée, il est temps de passer de Grow → Cloud, ou Cloud → Pro.
3. **Nettoyez régulièrement** : révisions, brouillons, transients, logs WooCommerce.
4. **Désactivez ou retirez les plugins inactifs**, et limitez les builders gourmands si vous en empilez plusieurs.
5. **Compressez les images** (WebP) et servez-les via Cloudflare ou BunnyCDN pour soulager l’I/O.
6. **Réservez les “Lunes”** pour isoler les quelques sites les plus bruyants (un gros WooCommerce, un client qui veut son propre accès cPanel).

## 8. Verdict rapide

| Profil | Offre conseillée | Pourquoi |
| --- | --- | --- |
| Freelance / TPE (≤ 10 vitrines) | **Grow** | Bon rapport prix/ressources, 4 Lunes suffisent |
| Agence avec portefeuille varié (≤ 50 sites) | **Cloud** | + 50 % de CPU, 48 Go de RAM, 8 Lunes |
| Studio e-commerce ou multi-sites intensifs | **Pro** | 24 threads, 64 Go de RAM, I/O × 5 |

> wp:paragraph 
> **En résumé :** le « tout illimité » existe surtout pour les fichiers. Pour WordPress, comptez plutôt **la trentaine de sites par tranche de 8 threads CPU** et montez d’un cran quand vos graphs commencent à rougir. Vous éviterez le fameux mail « Resources temporarily unavailable » au beau milieu de la nuit !
>  /wp:paragraph

— Christophe Marcellin, Éditeur web indépendant | High-Tech, IA, SEO et tutoriels · 4 novembre 2026