Estructura de WordPress 7.x: guía de carpetas, archivos y base de datos

WordPress no es solo una carpeta con archivos. Es un núcleo PHP, un conjunto de temas y plugins, una base de datos MySQL y una jerarquía de plantillas que decide qué se muestra en cada URL. Entender esa estructura te ahorra horas cuando toca mantener, depurar, actualizar, optimizar o proteger una web.

Esta guía está pensada para WordPress 7.x, la versión actual. Si vienes de una instalación estándar, todo lo que verás aquí te resultará familiar.

1. Arquitectura general

WordPress se organiza en cuatro capas: el núcleo, el contenido y las extensiones, la configuración y la base de datos. El núcleo está en wp-admin/ y wp-includes/. Lo que tú añades vive en wp-content/. La configuración está en wp-config.php. Y los datos —entradas, páginas, usuarios, opciones— están en MySQL o MariaDB.

El resultado es un CMS que se puede extender sin tocar el núcleo: los temas controlan la capa visual, los plugins añaden funcionalidad y los hooks permiten que ambos se comuniquen con WordPress.

2. Estructura de carpetas en la raíz

Esta es la estructura típica de una instalación de WordPress. Algunos archivos pueden no existir según el servidor, los plugins o la configuración.

wordpress/
├── wp-admin/               # Panel de administración (núcleo)
├── wp-content/             # Temas, plugins, uploads, idiomas...
│   ├── themes/
│   ├── plugins/
│   ├── mu-plugins/
│   ├── uploads/
│   ├── languages/
│   ├── upgrade/
│   └── cache/              # Creada por plugins de caché
├── wp-includes/            # Núcleo: funciones, clases, REST API, editor
├── wp-config.php           # Configuración (sensible)
├── wp-config-sample.php    # Plantilla de configuración
├── index.php               # Punto de entrada del front
├── wp-load.php             # Carga WordPress
├── wp-settings.php         # Arranque del núcleo
├── wp-blog-header.php      # Carga el entorno y la plantilla
├── wp-login.php            # Acceso al panel
├── wp-cron.php             # Tareas programadas
├── wp-mail.php             # Procesamiento de correo entrante
├── wp-signup.php           # Registro multisitio
├── wp-trackback.php        # Trackbacks
├── xmlrpc.php              # API XML-RPC
├── .htaccess               # Reescritura y seguridad (Apache/LiteSpeed)
├── .maintenance            # Modo mantenimiento temporal
├── readme.html
└── license.txt

No todo lo que aparece en wp-content/ es de WordPress. Carpetas como cache/, uploads/elementor/ o uploads/woocommerce_uploads/ las crean plugins o temas. Y archivos como advanced-cache.php, object-cache.php o db.php son drop-ins: los carga WordPress automáticamente si existen.

El archivo .htaccess solo se usa en Apache y LiteSpeed. En Nginx, la reescritura y las reglas de seguridad van en la configuración del servidor. El archivo .maintenance aparece cuando WordPress entra en modo mantenimiento; si se queda atascado, se elimina.

3. wp-content/: el espacio de trabajo

Si solo tienes que recordar una carpeta, que sea wp-content/. Aquí vive todo lo que no es núcleo y es donde se hacen la mayoría de las personalizaciones.

Dentro de uploads/ pueden convivir carpetas de terceros: elementor/ con CSS generado y fuentes, woocommerce_uploads/ con descargables, etc. No edites esos archivos generados: si usas Elementor, regenera el CSS desde su panel; si usas WooCommerce, revisa la configuración del plugin.

Los drop-ins son archivos especiales que WordPress detecta y carga desde wp-content/. Los más habituales son advanced-cache.php (caché avanzada), object-cache.php (caché de objetos) y db.php (capa de base de datos). Si un plugin de caché los instala, no los borres a mano sin desactivar el plugin primero.

4. wp-admin/ y wp-includes/

wp-admin/ es el panel de administración. Contiene las pantallas del escritorio, la gestión de entradas, usuarios, plugins, temas, ajustes, AJAX y los assets del panel. wp-includes/ es el núcleo del front y de la API: funciones, clases, el editor de bloques, la REST API, los endpoints y las librerías internas.

Ambas carpetas se actualizan con WordPress. Si las modificas, la actualización las sobrescribe. Si sospechas que han sido modificadas, no las “arregles” a mano: reinstala el núcleo desde una copia oficial, compara con los checksums y restaura desde una copia limpia.

Si buscas una intrusión, revisa primero wp-content/, los plugins, el tema, uploads/ y la configuración. El núcleo también puede comprometerse, pero lo habitual es que el atacante entre por un plugin, un tema o credenciales y busque persistencia fuera del núcleo. Tienes más detalle en Intrusiones en WordPress: análisis más técnico y soluciones.

5. wp-config.php

wp-config.php es el archivo de configuración principal. Está en la raíz de WordPress, aunque puede moverse un nivel por encima del directorio público para protegerlo. Contiene las credenciales de la base de datos, el prefijo de tablas, las sales de seguridad y varias constantes de comportamiento.

Las sales se generan desde la API de claves secretas de WordPress. Si las cambias, se invalidan las sesiones y todos los usuarios tendrán que volver a iniciar sesión. No las reutilices entre sitios ni las subas a un repositorio público.

En producción, WP_DEBUG debe estar en false. Si necesitas investigar un error, activa WP_DEBUG_LOG y revisa wp-content/debug.log; no muestres errores en pantalla a los visitantes. Y no edites wp-config.php en caliente sin copia de seguridad: un punto y coma mal puesto deja la web fuera de juego.

6. Temas: clásicos, bloques y child themes

El tema controla la capa visual. WordPress admite dos modelos: temas clásicos, basados en plantillas PHP, y temas de bloques, basados en plantillas HTML y theme.json. Muchos temas actuales son híbridos: usan PHP para la estructura y el editor de bloques para el contenido.

Tema clásico

mi-tema/
├── style.css              # Cabecera del tema y estilos
├── functions.php          # Funciones, hooks y assets
├── index.php              # Plantilla de respaldo
├── header.php
├── footer.php
├── sidebar.php
├── single.php             # Entrada individual
├── page.php               # Página estática
├── archive.php            # Archivos y categorías
├── search.php
├── 404.php
├── comments.php
├── template-parts/        # Partes reutilizables
├── inc/                   # Código auxiliar
├── assets/                # CSS, JS e imágenes
└── screenshot.png

Tema de bloques

mi-tema-bloques/
├── style.css
├── theme.json             # Ajustes y estilos globales
├── functions.php
├── templates/
│   ├── index.html
│   ├── single.html
│   ├── page.html
│   ├── archive.html
│   └── 404.html
├── parts/
│   ├── header.html
│   └── footer.html
├── patterns/
├── assets/
└── screenshot.png

La forma correcta de personalizar un tema sin perder cambios es crear un tema hijo. Su style.css incluye la cabecera del tema y la línea Template: tema-padre; su functions.php encola los estilos del padre y del hijo. Solo sobrescribes las plantillas que necesitas.

theme.json permite definir colores, tipografías, espaciados y ajustes de bloque desde un solo archivo. Es la base de los temas de bloques, pero también puede usarse en temas clásicos para limitar opciones del editor.

Si usas Elementor, muchas plantillas y ajustes se guardan en la base de datos, no en archivos del tema. El CSS generado suele estar en wp-content/uploads/elementor/css/. No edites esos archivos: regenera el CSS desde Elementor cuando hagas cambios. El tema sigue aportando la cabecera, el pie y la estructura base.

Si necesitas un tema a medida o una web corporativa con WordPress, en Solusen trabajamos con diseño web con WordPress.

7. Plugins y mu-plugins

Los plugins añaden funcionalidad sin tocar el núcleo. Cada uno vive en su carpeta dentro de wp-content/plugins/ y tiene un archivo principal con una cabecera que WordPress lee para mostrarlo en el panel.

mi-plugin/
├── mi-plugin.php          # Archivo principal con la cabecera
├── includes/              # Clases y funciones internas
├── admin/                 # Pantallas y lógica del back office
├── public/                # Lógica del front
├── assets/                # CSS, JS e imágenes
├── languages/             # Traducciones
├── vendor/                # Dependencias Composer
├── uninstall.php          # Limpieza al desinstalar
└── readme.txt

La cabecera del archivo principal incluye datos como Plugin Name, Description, Version, Author, Requires at least, Requires PHP, Text Domain y License. WordPress usa esa información para gestionar el plugin y las actualizaciones.

Los plugins se comunican con WordPress mediante hooks: acciones (add_action) y filtros (add_filter). Esa es la forma correcta de extender el comportamiento sin modificar el núcleo. Si un plugin necesita datos propios, lo normal es que cree sus propias tablas o use wp_options/wp_postmeta según el caso.

La carpeta mu-plugins/ carga plugins de forma obligatoria, sin activación manual. Es útil para código imprescindible de la instalación, pero no para cosas que quieras poder desactivar fácilmente. Los archivos deben estar directamente en wp-content/mu-plugins/ o cargarse desde un archivo puente.

Antes de instalar un plugin, revisa su mantenimiento, compatibilidad con tu versión de WordPress y PHP, y su historial de seguridad. Un plugin abandonado es una puerta de entrada. Si sospechas de una intrusión, revisa nuestra guía sobre los ataques más habituales en WordPress.

8. Jerarquía de plantillas

Cuando alguien visita una URL, WordPress no carga una plantilla al azar. Sigue una jerarquía: busca el archivo más específico en el tema y, si no lo encuentra, baja al siguiente. Entender esta cadena es básico para saber qué archivo estás editando.

En temas de bloques, la jerarquía se resuelve con archivos HTML dentro de templates/: single.html, page.html, archive.html, index.html, etc. Los archivos de parts/ se insertan como partes reutilizables (cabecera, pie).

Un ejemplo: si una entrada tiene el slug estructura-wordpress, WordPress buscará primero single-post-estructura-wordpress.php; si no existe, single-post.php, luego single.php, después singular.php y, como último recurso, index.php. Si el tema no tiene ninguna, WordPress usa la plantilla de respaldo.

Dos archivos que conviene diferenciar: front-page.php se usa para la portada, sea estática o el blog; home.php se usa para la página de entradas cuando la portada es una página estática. Si algo no aparece donde esperas, revisa primero esta jerarquía.

9. La base de datos

WordPress usa MySQL o MariaDB. El prefijo por defecto es wp_, aunque se puede cambiar durante la instalación. Se define en wp-config.php mediante $table_prefix. Si lo cambias después, necesitas migrar los datos y actualizar la configuración; no lo hagas a la ligera.

Dentro de wp_posts, la columna post_type distingue el tipo de contenido: post, page, attachment, revision, nav_menu_item, wp_block, wp_template, wp_template_part, wp_global_styles, wp_navigation, elementor_library, custom_css o customize_changeset. La columna post_status indica si está publicada, en borrador, pendiente, privada, programada, en papelera o es una revisión.

Dos ideas clave: wp_postmeta es una tabla clave-valor que puede crecer mucho; y wp_options almacena opciones con autoload, que se cargan en cada petición. Si tienes demasiadas opciones autocargadas o metadatos huérfanos, la web se ralentiza.

Una consulta de lectura habitual para revisar las últimas entradas sería:

SELECT ID, post_title, post_date
FROM wp_posts
WHERE post_type = 'post'
  AND post_status = 'publish'
ORDER BY post_date DESC
LIMIT 10;

Cambia el prefijo wp_ si tu instalación usa otro. Para modificaciones, usa el panel, un plugin o WP-CLI; no edites tablas a mano sin copia de seguridad. WP-CLI tiene comandos muy útiles:

wp db export
wp db import
wp search-replace 'https://old.com' 'https://new.com' --all-tables
wp post list
wp plugin list
wp theme list
wp cache flush
wp rewrite flush

Si necesitas profundizar, la guía oficial The WordPress Database y la Metadata API son buenos puntos de partida.

10. Flujo de una petición

Cuando un visitante entra en la web, WordPress sigue un recorrido concreto. Entenderlo ayuda a depurar y a saber en qué capa buscar.

Petición del navegador
        ↓
index.php
        ↓
wp-blog-header.php
        ↓
wp-load.php → wp-config.php → wp-settings.php
        ↓
wp()
        ↓
WP_Query
        ↓
template-loader.php
        ↓
Plantilla del tema
        ↓
Respuesta HTML

• Front: index.php carga el entorno, se ejecuta la consulta principal y se resuelve la plantilla según la jerarquía.
• Back office: se entra por wp-admin/; se carga WordPress, se comprueban permisos y se renderiza la pantalla correspondiente.
• REST API: las peticiones a /wp-json/ se enrutan con rest_api_init y sus callbacks.
• Cron: wp-cron.php ejecuta tareas programadas cuando hay tráfico, salvo que uses cron real del servidor.

Para depurar, activa WP_DEBUG y WP_DEBUG_LOG solo en staging, revisa wp-content/debug.log y los logs del servidor. Si el error aparece tras activar un plugin o cambiar una plantilla, el problema suele estar ahí, no en el núcleo.

11. Dónde tocar cada cosa

Esta tabla resume la decisión más importante: qué archivo o zona usar según lo que quieras cambiar.

12. Buenas prácticas y errores comunes

La estructura de WordPress está pensada para extenderse, no para modificarse a lo bruto. Estas son las reglas que evitan la mayoría de los problemas:

• No edites wp-admin/, wp-includes/ ni el tema padre.
• Usa un tema hijo para el diseño y un plugin propio para la funcionalidad.
• Mantén actualizados WordPress, temas, plugins y PHP; elimina lo que no uses.
• Haz copias de seguridad de archivos y base de datos antes de cualquier cambio importante.
• Prueba en staging y verifica el front, el panel y el proceso de compra si hay tienda.
• Activa DISALLOW_FILE_EDIT y desactiva WP_DEBUG en producción.
• Usa contraseñas fuertes, doble factor y mínimo privilegio para los usuarios.
• Permisos 755 para directorios y 644 para archivos; wp-config.php en 600 si el hosting lo permite.
• Bloquea la ejecución de PHP en uploads/ y protege wp-config.php, xmlrpc.php y readme.html si no los usas.
• Limita revisiones, limpia transients y no acumules plugins innecesarios.
• Si desactivas WP_CRON, configura un cron real en el servidor.
• Monitoriza logs, uptime, integridad de archivos y accesos.

La seguridad también forma parte de la estructura. Un plugin abandonado, un tema pirata o un wp-config.php expuesto pueden arruinar la mejor web. Si sospechas de una intrusión, revisa el análisis técnico de intrusiones en WordPress, la guía de ataques habituales y el artículo sobre PHP Shell.

13. Preguntas frecuentes sobre la estructura de WordPress

14. Conclusión

Conocer la estructura de WordPress te permite saber dónde está cada cosa, qué se puede tocar y qué conviene dejar quieto. La regla de oro es sencilla: extiende antes de modificar, usa un tema hijo, prueba en staging y haz copia antes de cambiar. Con eso, la mayoría de los problemas se evitan antes de que aparezcan.

Si tu web WordPress necesita mantenimiento, una revisión de seguridad o una migración, podemos ayudarte.