WordPress es un gestor de contenidos de código abierto que permite publicar y administrar un sitio sin escribir código. Lo primero que hay que aclarar es la confusión entre WordPress.org, el software libre que instalás donde quieras y controlás por completo, y WordPress.com, un servicio comercial con planes que usa ese software. Los requisitos vigentes son PHP 8.3 o superior, MariaDB 10.11+ o MySQL 8.0+ y HTTPS «requerido en cada instalación». La instalación es la parte fácil; lo que decide si el sitio sigue en pie dentro de dos años son dos cosas: cuántos complementos tiene y con qué frecuencia se actualiza.
Ver índice de contenidos
Qué es y qué resuelve
Un gestor de contenidos separa el contenido de la presentación: los textos y las imágenes viven en una base de datos, el diseño vive en un tema, y una persona sin conocimientos técnicos puede publicar sin tocar HTML.
Eso es lo que resuelve WordPress, y lo hace tan bien que se volvió el gestor más usado de la web. Su ventaja real no es técnica sino de ecosistema: hay temas y complementos para casi cualquier necesidad, documentación en todos los idiomas y mucha gente que sabe usarlo.
Su desventaja viene del mismo lugar. Ser el más usado lo convierte en el objetivo más rentable para los barridos automáticos, y el ecosistema de complementos es a la vez su mejor función y su principal fuente de problemas.
.org o .com
Son dos cosas distintas con nombres casi idénticos, y elegir mal cuesta una migración:
| WordPress.org | WordPress.com | |
|---|---|---|
| Qué es | El software libre, para instalar donde quieras | Un servicio comercial que lo aloja por vos |
| Alojamiento | Lo contratás aparte | Incluido en el plan |
| Complementos y temas | Cualquiera | Solo desde cierto plan en adelante |
| Actualizaciones y respaldos | Tu responsabilidad | Del proveedor |
| Control | Total: es tu servidor | El que permita el plan |
El criterio: si querés control y no te asusta mantenerlo, .org. Si preferís publicar y que otro se ocupe, .com o un alojamiento administrado. Esta guía trata el primer caso, que es el que exige decisiones.
Los requisitos vigentes
La página oficial de requisitos es breve y conviene leerla antes de contratar alojamiento, porque descarta proveedores:
PHP: «Versión 8.3 o superior.»
Base de datos: «MariaDB 10.11+ o MySQL 8.0+.»
HTTPS: «Requerido en cada instalación.»
Los dos primeros son los que hay que verificar antes de pagar: un proveedor que solo ofrece versiones viejas de PHP es un problema con fecha, porque las versiones sin soporte dejan de recibir parches de seguridad. El tercero hoy es gratis y automático en casi cualquier proveedor —ver SSL, TLS y certificados—, así que no hay excusa.
La instalación en sí suele resolverse con el instalador del panel de control. Si se hace a mano son cuatro pasos: crear la base de datos y su usuario, subir los archivos, completar el formulario de configuración y crear la cuenta administradora. En esa cuenta, dos decisiones que después cuesta cambiar: un nombre de usuario que no sea «admin» y una contraseña larga y única.
Anatomía de una instalación
Cuatro piezas, y entender qué hace cada una es lo que permite diagnosticar cuando algo se rompe:
- El núcleoLos archivos de WordPress. Se actualiza entero y no se modifica nunca: cualquier cambio se pierde en la próxima actualización.
- El temaLa presentación. Se cambia sin perder el contenido.
- Los complementosLas funciones que se agregan. Acá está la mayor parte del riesgo.
- La base de datos y las subidasEl contenido real: entradas, páginas, configuración, imágenes. Lo único irreemplazable.
Esa última fila define qué es un respaldo válido: hacen falta las dos cosas, base de datos y archivos subidos. Con solo una de las dos no se reconstruye el sitio. El núcleo, los temas y los complementos se vuelven a descargar.
Temas
El tema define cómo se ve el sitio. Al elegirlo, dos criterios pesan más que el diseño:
- Que se mantenga. Un tema sin actualizaciones recientes es un riesgo, igual que un complemento abandonado.
- Que no traiga funcionalidad. Muchos temas comerciales incluyen tipos de contenido y campos propios. Si algún día cambiás de tema, ese contenido desaparece. La funcionalidad va en complementos; el tema solo debería ocuparse de la presentación.
Y una regla que evita perder trabajo: no editar el tema directamente. Para modificarlo se usa un tema hijo, que hereda todo del original y solo contiene tus cambios. Sin eso, la próxima actualización del tema borra las modificaciones.
Complementos: el criterio
Acá se decide la salud del sitio a mediano plazo, y la clave está en una idea incómoda: un complemento es código de terceros que corre con permisos totales dentro de tu sitio. Puede leer y escribir la base de datos entera, incluidas las cuentas de usuario. Instalar quince es aceptar código de quince equipos que no conocés.
Cinco preguntas antes de instalar cualquiera:
- ¿Cuándo se actualizó por última vez? Más de un año sin cambios es señal de abandono. Está en el directorio oficial.
- ¿Cuánta gente lo usa? Más instalaciones significan más ojos encima y parches más rápidos.
- ¿Declara compatibilidad con la versión actual? Si dice que fue probado con una versión de hace tres años, ya sabés.
- ¿Puedo resolverlo sin complemento? Para agregar tres líneas de código no hace falta uno.
- ¿Qué pasa si lo desinstalo? Algunos dejan el contenido inutilizable. Conviene saberlo antes.
Los que casi siempre valen la pena son pocos: uno de respaldos, uno de seguridad, uno de caché si el alojamiento no la trae, uno de posicionamiento y uno de formularios. Con eso está cubierto casi todo lo que un sitio común necesita.
La rutina de mantenimiento
Un sitio sin mantenimiento no se queda quieto: se degrada. La rutina completa son cuatro pasos y no lleva más de quince minutos:
- Respaldar antes de tocar nadaBase de datos y archivos. Este paso es el que convierte un problema en un susto.
- ActualizarNúcleo, temas y complementos. Las de seguridad, apenas salen.
- VerificarEntrar al sitio y probar lo crítico: la portada, el formulario de contacto, el proceso de compra si lo hay.
- LimpiarDesinstalar —no solo desactivar— lo que ya no se usa. Un complemento desactivado sigue siendo código en el servidor.
Sobre las actualizaciones automáticas: las de seguridad del núcleo conviene dejarlas activadas siempre, porque el riesgo de no aplicarlas es mayor que el de una incompatibilidad. Para las de complementos, en un sitio del que dependen ingresos, es preferible aplicarlas a mano después de un respaldo.
El punto cuatro merece énfasis: desactivar no es desinstalar. Los archivos siguen en el servidor y una vulnerabilidad en un complemento desactivado puede seguir siendo explotable.
Seguridad mínima
Conviene entender cómo son los ataques reales: casi nunca hay alguien que elige tu sitio. Hay barridos automáticos que prueban vulnerabilidades conocidas en millones de direcciones. El blog de Underc0de documentó una campaña que comprometió más de 3.500 sitios exactamente así.
La consecuencia es alentadora: como no sos un objetivo elegido, alcanza con no ser el más fácil. Ocho medidas cubren casi todo:
- Actualizar. Es la medida más efectiva, por lejos.
- Nada de usuario «admin». Es el nombre que prueban primero.
- Doble factor en las cuentas administradoras.
- Limitar los intentos de acceso. Frena la prueba masiva de contraseñas.
- Menos cuentas y menos permisos. Quien solo publica no necesita ser administrador.
- Desactivar el editor de archivos del panel. Con una línea en la configuración. Si roban una cuenta, evita que suban código desde el navegador.
- HTTPS obligatorio con redirección.
- Respaldos fuera del servidor y probados alguna vez.
Cuándo no usar WordPress
Es una herramienta muy buena para lo que hace, y se usa seguido para lo que no:
| Si el sitio es… | Conviene | Por qué |
|---|---|---|
| Una landing o un portfolio que casi no cambia | Sitio estático | Más rápido, gratis de alojar y sin nada que mantener |
| Documentación técnica versionada | Generador estático | El contenido vive en el repositorio, junto al código |
| Una aplicación con lógica propia | Desarrollo a medida | Forzarlo como aplicación termina en una maraña de complementos |
| Un blog con mucho contenido y edición frecuente | WordPress | Es exactamente para lo que fue hecho |
| Un sitio que otra persona va a administrar | WordPress | El panel es conocido y hay gente que sabe usarlo |
El último caso pesa más de lo que parece. Si el sitio lo va a mantener alguien sin perfil técnico, un gestor conocido vale más que una solución técnicamente más elegante que nadie sepa tocar.
Errores frecuentes
- Instalar complementos sin criterio. Cada uno es código de terceros con permisos totales.
- Dejar el usuario «admin». Es el primero que prueban.
- Editar el tema sin usar un tema hijo. La próxima actualización borra los cambios.
- Elegir un tema que trae funcionalidad. Cambiar de tema se lleva el contenido.
- Postergar las actualizaciones «para no romper nada». Un sitio desactualizado se rompe solo, pero de otra manera.
- Desactivar en lugar de desinstalar. Los archivos siguen ahí y siguen siendo explotables.
- Respaldar solo la base de datos. Sin la carpeta de subidas no se recupera nada visual.
- Usarlo para un sitio que no cambia nunca. Un sitio estático sería más rápido y más seguro.
Preguntas frecuentes
¿Cuál es la diferencia entre WordPress.org y WordPress.com?
WordPress.org es el software libre: lo instalás en el alojamiento que quieras, tenés control total y las actualizaciones, los respaldos y la seguridad quedan a tu cargo. WordPress.com es un servicio comercial que aloja ese mismo software y se ocupa del mantenimiento, a cambio de menos libertad, con restricciones sobre qué complementos y temas se pueden usar según el plan. El criterio para elegir es simple: si querés control y podés mantenerlo, la versión instalable; si preferís publicar y que otro se ocupe, el servicio alojado.
¿Qué requisitos tiene WordPress hoy?
La documentación oficial recomienda PHP en versión 8.3 o superior y como base de datos MariaDB 10.11 o superior, o MySQL 8.0 o superior. Además declara que HTTPS es requerido en cada instalación. Los dos primeros conviene verificarlos antes de contratar alojamiento, porque descartan proveedores: uno que solo ofrezca versiones viejas de PHP es un problema con fecha, ya que las versiones sin soporte dejan de recibir parches de seguridad. El tercero hoy es gratis y automático en casi cualquier proveedor.
¿Cuántos complementos son demasiados?
No hay un número, pero sí un criterio: cada complemento es código de terceros que corre con permisos totales dentro del sitio y puede leer y escribir toda la base de datos. La cantidad instalada es una medida directa de la superficie de ataque y del trabajo de mantenimiento. Antes de instalar uno conviene preguntarse cuándo se actualizó por última vez, cuánta gente lo usa, si declara compatibilidad con la versión actual, si el mismo trabajo se puede hacer sin él y qué pasa con el contenido si algún día se desinstala.
¿Qué hay que respaldar exactamente?
Dos cosas, y hacen falta las dos: la base de datos, donde viven las entradas, las páginas, los comentarios y la configuración, y la carpeta de subidas, donde están las imágenes y los archivos cargados. Eso es lo único verdaderamente irreemplazable; el núcleo, los temas y los complementos se vuelven a descargar. Un respaldo que tenga solo la base de datos deja un sitio sin imágenes, y uno que tenga solo los archivos deja un sitio sin contenido. Y conviene guardarlos fuera del mismo servidor.
¿Por qué se hackean tantos sitios de WordPress?
Por su popularidad y por el ecosistema de complementos, no porque el software sea inseguro en sí. Al ser el gestor más usado, es el objetivo más rentable para los barridos automáticos que prueban vulnerabilidades conocidas en millones de direcciones. La buena noticia es que casi nunca hay alguien que elija tu sitio en particular: como el ataque es automático y masivo, alcanza con no ser el blanco más fácil. Actualizar, no usar el usuario «admin», poner doble factor y limitar los intentos de acceso cubre la enorme mayoría de los casos.
¿Conviene WordPress para cualquier sitio?
No. Para una landing o un portfolio que casi no cambian, un sitio estático es más rápido, más seguro, más barato y no tiene nada que mantener. Para documentación técnica versionada, un generador estático mantiene el contenido junto al código. Y para una aplicación con lógica propia, forzarlo termina en una maraña de complementos difícil de sostener. WordPress brilla en lo que fue hecho: sitios con contenido que se edita seguido, y sobre todo aquellos que va a administrar alguien sin perfil técnico.
Fuentes
Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 27 de julio de 2026.
Aportes de la comunidad Underc0de
- Underc0de, blog. Campaña global de cryptojacking: más de 3.500 sitios web comprometidos, 21 de julio de 2025. El destino habitual de una instalación desatendida.
- Underc0de, foro. Sección Programación web. Consultas de la comunidad sobre gestores de contenido y desarrollo de sitios.
Documentación oficial
- WordPress. Requirements. Las versiones recomendadas de PHP y base de datos y la exigencia de HTTPS, citadas textualmente.
- WordPress. Documentation. Manual oficial de instalación, configuración y administración.
- WordPress. Hardening WordPress. Recomendaciones oficiales de endurecimiento.
- WordPress. Directorio de complementos. Donde figuran las fechas de actualización y la compatibilidad declarada.