Análisis en profundidad del código de un tema WordPress a medida: qué revisar y con qué herramientas

Un tema a medida no pasa por el repositorio de WordPress.org. No tiene historial público de vulnerabilidades, ningún escáner lo conoce de antemano y nadie ha revisado su código salvo quien lo escribió, que a veces es la única persona en el mundo que sabe qué hay dentro, y normalmente ya no trabaja en el proyecto.

Hay tres posibles situaciones en las que se me ocurre que este artículo te va a resultar útil:

1. Has encargado que te desarrollen un tema a medida y quieres saber si lo que te han entregado es sólido antes de que llegue tráfico real.
2. Tu equipo asume el mantenimiento de una web que no conoce, y el tema a medida es ese territorio sin documentar donde se concentran los apaños, los atajos y los retoques de todo el que ha pasado por el proyecto antes que tú.
3. Te encargan mejorar, actualizar o rediseñar un tema existente, y antes de escribir una sola línea nueva necesitas saber sobre qué base estás trabajando.

En los tres casos la revisión es la misma, lo que cambia es el momento en que la haces y lo que puedes decidir con los resultados.

El artículo va en dos velocidades, de manera que si no te manejas con código cada bloque te indica qué puedes detectar con herramientas visuales y qué pedirle a una IA, y por otro lado, si eres el técnico del proyecto, encontrarás el análisis estático, los comandos y el nivel de detalle que completan el trabajo.

Pretende ser una guía para todo tipo de perfiles, aunque no te veas del todo en los propuestos, lo importante es que nadie se quede sin información útil, incluso si simplemente quieres leerlo para aprender o pillar ideas.

Entorno y herramientas

Antes de revisar una sola línea de código conviene tener preparado lo que vas a necesitar. No es mucho, pero todo imprescindible.

Si no te manejas con código

Lo primero es activar el modo depuración de WordPress. Abre el archivo wp-config.php de tu instalación de pruebas (nunca en producción) y añade estas tres líneas antes de la que dice «That’s all, stop editing!»:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Con esto WordPress empezará a registrar en un archivo debug.log cualquier función obsoleta, aviso de compatibilidad o error que aparezca al navegar por la web. Para leer ese archivo sin salir del administrador instala Debug Log Manager. Luego instala también el plugin oficial Health Check & Troubleshooting, que entre otras cosas te muestra la versión de PHP activa y el estado general de la instalación.

Con esas dos herramientas y una IA (Claude o cualquier otra) ya puedes revisar la mayor parte de lo que este artículo cubre.

Si eres el técnico del proyecto

La combinación que cubre la mayor parte del análisis estático son PHP CodeSniffer con los WordPress Coding Standards y el paquete PHPCompatibility. Con esa combinación puedes detectar problemas de compatibilidad PHP, funciones obsoletas y violaciones de los estándares de WordPress sin ejecutar el código, solo analizando los archivos.

Para análisis en tiempo real mientras navegas la instalación, Query Monitor es la referencia. Y WP-CLI para los comandos que se mencionan a lo largo del artículo.

Si quieres una auditoría asistida por IA de toda la carpeta del tema de una vez, Claude Code con la instrucción inicial sobre el directorio completo es la forma más rápida de tener un primer mapa de problemas priorizado.

Compatibilidad con PHP

Un tema con funciones eliminadas en PHP 8.x no da aviso: da error crítico. Es el tipo de problema que aparece el día que el hosting actualiza la versión de PHP, que es exactamente lo que van a hacer tarde o temprano.

Sin código, WP_DEBUG + Debug Log te avisa de las funciones obsoletas en cuanto navegas por la web con el tema activo. Health Check te muestra la versión de PHP que tienes y si el tema declara una versión mínima compatible.

Con código, PHP CodeSniffer + PHPCompatibility analiza el tema completo sin ejecutarlo, incluyendo archivos que quizás no se llaman en ninguna URL de prueba.

Para el nivel sin código también puedes pegar el contenido de functions.php en una IA con el prompt: «Eres revisor de código PHP. Identifica funciones PHP eliminadas o incompatibles con PHP 8.x en este código de tema WordPress. Para cada caso dime el nombre de función, el número de línea y la alternativa recomendada.»

Crítico

• Uso de funciones eliminadas en PHP 8.x: ereg(), ereg_replace(), mysql_*, create_function(), each(), split(). Si aparecen en el código, el tema puede dejar de funcionar en cualquier actualización de PHP.
• Operador @ usado de forma sistemática para suprimir errores: oculta fallos reales y puede romper el comportamiento en PHP 8 sin aviso ninguno.

Importante

• Comparaciones con == en contextos donde PHP 8 cambia el comportamiento (cadenas numéricas, comparaciones con null): el código parece funcionar pero produce resultados incorrectos en determinadas condiciones.
• Versión PHP mínima declarada en la cabecera del tema muy por debajo de la que el código realmente necesita. Si el tema dice Requires PHP: 5.6 pero usa sintaxis de PHP 7.4, la declaración es incorrecta y puede inducir a error al gestor del hosting.

Menor

• Sintaxis PHP 7.0-7.3 que funciona en 8.x pero no aprovecha las mejoras disponibles: planificable para la próxima iteración, no urgente.
• Ausencia de typed properties o tipado de parámetros: no es un error, es una omisión de buenas prácticas.

Nota importante para WordPress 7.x: el núcleo sube el mínimo a PHP 7.4. Cualquier tema que declare una versión inferior necesita actualizar esa cabecera y revisar el código si usaba sintaxis más antigua.

Funciones de WordPress obsoletas

Una función obsoleta no rompe hoy, pero romperá cuando WordPress decida eliminarla. Y eso pasa en cada versión mayor. La diferencia entre una función obsoleta y una eliminada es solo tiempo.

WP_DEBUG registra los avisos de obsolescencia en el log cada vez que el tema llama a una función que ya no debería usar. Con eso y el log ya tienes la lista. Para el perfil técnico, PHP CodeSniffer con WPCS detecta las funciones obsoletas sin necesidad de ejecutar el tema.

Crítico

• Funciones de WordPress eliminadas del todo (no solo obsoletas): si aparecen en el código, el tema puede dar un error crítico en la próxima actualización del núcleo.
• Modificaciones directas de archivos de wp-includes o wp-admin desde el tema: raro en proyectos modernos, pero ocurre en temas muy antiguos que «parchearon» algo del núcleo directamente.

Importante

• Funciones obsoletas con aviso pero que siguen funcionando: wp_title() (obsoleta desde WP 4.4), get_currentuserinfo(), the_attachment_link(). Funcionan hoy, pero hay que planificar la sustitución.
• Código que asume que el directorio wp-content está en su ruta por defecto usando rutas absolutas literales, en lugar de las constantes WP_CONTENT_DIR o WP_CONTENT_URL.
• Hooks que fueron renombrados pero los originales siguen como alias: el alias puede desaparecer en una versión mayor sin previo aviso adicional.

Menor

• Widgets registrados solo con la API clásica sin compatibilidad con el editor de bloques: funcional hoy, pero visible como deuda si el cliente trabaja con Gutenberg.
• Template files que no usan get_template_part() donde deberían, con código de plantilla duplicado en varios archivos.

Hay una señal que merece párrafo aparte porque no rompe nada hoy pero crea un problema real el día que el cliente quiera cambiar de tema: funcionalidades de plugin metidas dentro del tema. CPTs, shortcodes globales, taxonomías personalizadas dentro de functions.php. Si el cliente cambia de tema, desaparece su contenido. Es Importante a corto plazo y Crítico como estado permanente de un proyecto.

Seguridad del código

Este bloque tiene solapamiento con el artículo sobre temas WordPress con código malicioso. Lo que cubre aquel artículo es código ofuscado, backdoors y malware. Lo que cubre este bloque son los problemas de seguridad que un desarrollador descuidado introduce sin mala intención: variables sin escapar, SQL sin preparar, ausencia de nonces. Son igual de peligrosos y mucho más frecuentes.

PHP CodeSniffer con WPCS detecta automáticamente la mayor parte de los problemas de escapado y sanitización. Para el nivel sin código, el prompt de IA más útil para este bloque es: «Identifica en este código PHP de un tema WordPress variables impresas sin escapar, datos de usuario sin sanitizar y consultas SQL sin usar $wpdb->prepare(). Explica cada caso en términos simples.»

Crítico

• Variables de $_GET, $_POST o $_REQUEST impresas directamente en el HTML sin sanitizar ni escapar: XSS directo.
• $wpdb->query(), $wpdb->get_results() o cualquier otra función de base de datos con interpolación directa de variables sin $wpdb->prepare(): inyección SQL activa.
• Formularios que procesan datos sin verificar nonce con check_admin_referer() o check_ajax_referer().
• Acciones de administración o procesamiento de datos sin current_user_can(): cualquier usuario puede ejecutar esas acciones.
• Uso de eval(), base64_decode() aplicado a variables externas, system() o exec(): señal de alerta máxima. Saltar directamente al artículo de código malicioso para saber qué hacer.

Importante

• echo get_the_title() sin esc_html(): XSS potencial en contextos concretos, no siempre explotable de forma inmediata, pero hay que corregirlo.
• Llamadas a APIs de terceros que envían datos de usuarios sin opción de desactivar y sin mención en la política de privacidad.
• Ausencia de sanitización en campos del Customizer que no se imprimen directamente en el front: riesgo no inmediato, pero es deuda documentada.

Menor

• Fuentes de Google cargadas desde fonts.googleapis.com sin opción de desactivar: problema de cumplimiento del RGPD, no de seguridad activa, pero requiere solución.
• Nonces ausentes en formularios de solo lectura que no modifican datos: bajo riesgo real, pero incumple los estándares de WordPress.

Rendimiento

Los problemas de rendimiento de un tema a medida no siempre aparecen en el desarrollo. Aparecen cuando la web tiene contenido real, con cientos de entradas y miles de visitas. Un N+1 que pasa desapercibido en desarrollo puede tumbar un servidor con tráfico real.

Query Monitor es la herramienta para ambos perfiles: se instala como plugin, no necesita configuración y muestra en tiempo real las queries que ejecuta cada carga de página, cuánto tarda cada una y de dónde viene. Para el resultado agregado, PageSpeed Insights da la imagen completa del impacto en el usuario.

Crítico

• WP_Query o get_posts() dentro de un bucle de posts: el N+1 clásico. Si tienes 50 entradas en un listado y cada una dispara su propia query adicional, son 51 queries donde debería haber 1 o 2.
• wp_remote_get() o llamadas curl en cada carga de página sin ninguna caché con transients: cada visita hace una petición HTTP a un servicio externo que puede tardar segundos o estar caído.
• jQuery propio incluido en la carpeta del tema cargando en paralelo al de WordPress: doble carga y conflictos de versión garantizados.

Importante

• Scripts y estilos encolados en todas las páginas sin condición cuando solo hacen falta en plantillas concretas: un slider de JavaScript cargando en cada entrada del blog aunque el slider solo esté en la portada.
• WP_Query sin 'no_found_rows' => true en consultas que no paginarán nunca: WordPress hace un COUNT(*) adicional innecesario. Coste medible con tráfico real.
• Opciones guardadas en wp_options con autoload=yes cuando no hacen falta en cada carga de página: se suman al peso de la consulta de opciones que WordPress ejecuta en cada petición.
• CSS crítico no inline, haciendo que el navegador espere una hoja de estilos externa antes de renderizar nada visible.

Menor

• Scripts encolados en el header que podrían ir al pie con el quinto parámetro a true en wp_enqueue_script().
• Imágenes del tema sin loading="lazy" donde procede.

Malas prácticas y estándares heredados

Este bloque cubre los problemas que no rompen nada hoy pero que hacen el mantenimiento difícil y el comportamiento impredecible. Son los que aparecen cuando hay que cambiar el dominio, migrar el proyecto a un nuevo servidor o simplemente actualizar algo que estaba «atado con alambres».

Crítico

• Funciones sin prefijo o con prefijo genérico: get_menu(), init(), setup(). Si en algún momento se activa un plugin que declara una función con el mismo nombre, el conflicto es un error fatal.
• IDs de páginas o entradas hardcodeados en la lógica del tema: if ( $post->ID === 42 ). Ese ID 42 no existe en el servidor de desarrollo, ni en el staging, ni en el siguiente proyecto que use el mismo tema base.
• Slugs de categorías o taxonomías hardcodeados en condicionales: mismo problema exacto que los IDs.
• URLs absolutas hardcodeadas al dominio de producción o de desarrollo: si el dominio cambia, el tema queda roto en silencio. Buscar cualquier cadena con https:// o http:// dentro del código PHP y las plantillas.

Importante

• Rutas absolutas de servidor hardcodeadas como /var/www/html/wp-content/themes/... en lugar de get_template_directory() o get_stylesheet_directory().
• Colores, dimensiones o configuraciones hardcodeadas en JavaScript que deberían venir de variables CSS o de opciones del Customizer: cuando el cliente quiere cambiar el color corporativo, toca editar código.
• Archivos de desarrollo dentro de la carpeta del tema: node_modules, .git, archivos .log, copias .bak, .DS_Store. Ninguno de esos tiene que llegar a producción.
• die() o exit() donde debería usarse wp_die(): WordPress pierde el control de la ejecución y el usuario recibe un pantallazo en blanco sin contexto.

Menor

• Cadenas de texto no envueltas en funciones de traducción (__(), _e()): el tema no es internacionalizable, pero no rompe nada. Planificable si el proyecto va a necesitar varios idiomas.
• functions.php de varios miles de líneas sin estructura de includes ni documentación: no rompe nada, pero hace el mantenimiento muy difícil.
• Comentarios en el código en el idioma del desarrollador original cuando no es el del equipo que hereda el proyecto.
• Código comentado con funcionalidades a medias o parches rápidos sin explicación.

Dependencias y servidumbres

Un tema a medida acumula dependencias que no siempre son visibles en el código. Algunas son técnicas, otras son contractuales. El momento de descubrirlas no es cuando algo deja de funcionar, sino antes de comprometerte a mantener el proyecto.

Crítico

• Plugins bundled (empaquetados) dentro de la carpeta del tema sin los cuales el tema da error crítico: si ese plugin falla, se desactiva o deja de existir en WordPress.org, la web se cae. Los plugins son plugins, van en su carpeta, no dentro del tema.
• Código que llama a is_plugin_active() sin manejar el caso de que el plugin no esté activo: en el momento en que alguien desactiva ese plugin por lo que sea, el tema da un error fatal.
• Librerías JavaScript o CSS de terceros copiadas dentro del tema con versiones que tienen vulnerabilidades conocidas. Buscar en Patchstack o WPScan las versiones incluidas.

Importante

• Dependencia de un page builder integrado en el tema de forma que desinstalarlo afecta al contenido existente: es una decisión de arquitectura que hay que documentar y comunicar al cliente.
• APIs de terceros integradas sin fallback: si la API no responde, ¿la página da error o simplemente no muestra esa sección? Hay que saberlo antes de que le pase al usuario.

Menor

• Fuentes de Adobe Fonts, Typekit u otros servicios de pago integrados sin documentar la licencia activa ni quién la controla: funciona mientras la licencia esté vigente, pero hay que saber quién paga eso.
• Tema hijo de un tema padre comercial (Divi, Avada, Genesis): la dependencia de la licencia del padre hay que documentarla y saber quién la controla.

SEO y estructura semántica

Aquí es donde más destrozos se acumulan en temas a medida y donde menos gente mira. Un tema puede pasar todos los controles anteriores y seguir siendo un problema grave para el posicionamiento y para los lectores de pantalla. La estructura semántica incorrecta no da error ninguno, pero Google y los motores de búsqueda la leen y la valoran cada vez que rastrean la página.

Para el propietario sin código, las herramientas más útiles aquí son el inspector del navegador (clic derecho > Ver código fuente para el HTML completo) y la extensión Headings Map para Chrome o Firefox, que visualiza el árbol completo de encabezados de una página de un vistazo. Lighthouse en DevTools detecta imágenes sin alt y otros problemas de accesibilidad. Para el análisis semántico asistido por IA, pegar el código fuente HTML completo de la página con el prompt: «Analiza la estructura de encabezados de este HTML. Dime cuántos H1 hay, si hay saltos de jerarquía y si algún encabezado está en un lugar estructuralmente incorrecto.»

Crítico

• Múltiples etiquetas <h1> en la misma página: el logotipo, el nombre del sitio y el título de la entrada con el mismo nivel de importancia. Google espera un solo <h1> por página.
• <h1> ausente en páginas de contenido o colocado en elementos decorativos sin contenido relevante.
• El tema genera su propia etiqueta <title> hardcodeada ignorando WordPress y el plugin SEO activo: el resultado es dos etiquetas <title> en el HTML.
• Meta description o canonical generados por el tema en paralelo a los del plugin SEO: conflicto directo entre dos fuentes que dicen cosas distintas.
• Etiquetas Open Graph (og:title, og:image, og:description) hardcodeadas en el tema: invalida completamente lo que configuren tanto el cliente como el plugin SEO.
• Schema markup emitido por el tema en paralelo al del plugin SEO: datos estructurados duplicados o contradictorios que Google puede ignorar o interpretar mal.
• Meta robots hardcodeado en el tema: puede estar bloqueando la indexación de páginas enteras sin que nadie lo sepa.

Importante

• Saltos de jerarquía de encabezados: pasar de <h1> a <h4> directamente porque visualmente quedaba mejor así.
• Encabezados <h2> o <h3> usados en menús de navegación, sidebars o footer por razones de estilo: rompen la jerarquía del contenido de cada página.
• Paginación implementada con JavaScript sin etiquetas <a href> reales: Google no puede rastrear el contenido paginado si no hay URLs enlazables.
• Botones de acción o elementos de navegación implementados con onclick o <div> sin href real: invisibles para Google y para el teclado.
• Imágenes sin atributo alt, incluso las decorativas que deberían llevar alt="": problema de accesibilidad y de SEO de imágenes.
• Links sin texto visible (solo icono sin aria-label): los motores de búsqueda no saben qué enlaza ese elemento.
• Microdata (itemscope, itemtype) incompleta o mezclada con JSON-LD del plugin SEO: la fuente única de schema debería ser el plugin SEO, no el tema.

Menor

• Imágenes con alt que contiene el nombre de archivo literal (IMG_4582.jpg): no aporta nada y el buscador lo sabe.
• Elementos semánticos HTML5 (<article>, <main>, <nav>, <footer>) ausentes o usados de forma incorrecta: impacto principalmente en accesibilidad, menor en SEO directo.
• Múltiples elementos <nav> sin aria-label que los distinga: los lectores de pantalla no pueden diferenciarlos.
• Atributos target="_blank" en links externos sin rel="noopener".
• Texto oculto con display:none o visibility:hidden sobre contenido con palabras clave: puede interpretarse como intento de manipulación aunque no lo sea.

Estructura general del código

Antes de tocar nada conviene saber exactamente qué tienes entre manos. No para arreglarlo de inmediato, sino para no romper algo que no sabías que existía.

Crítico

• Tema que es en realidad un tema padre comercial modificado directamente (Divi, Avada, Elementor Hello con cambios en los archivos del padre): en la próxima actualización del padre, los cambios desaparecen sin dejar rastro.
• Ausencia total de tema hijo cuando se trabaja sobre un tema padre: cualquier actualización borra las personalizaciones sin aviso.
• Código del tema que escribe o modifica archivos del servidor en tiempo de ejecución fuera de la carpeta de uploads: señal de alerta que puede ser un mecanismo de persistencia.

Importante

• functions.php monolítico de varios miles de líneas sin estructura de includes ni organización visible: funciona, pero el mantenimiento es costoso y el riesgo de romper algo al editar es alto.
• Mezcla de lógica de tema y lógica de negocio en los mismos archivos: hace difícil separar qué es el tema y qué es personalización específica del proyecto.

Menor

• Ausencia de changelog o historial de cambios, aunque sea en comentarios: no rompe nada, pero hace imposible saber qué se tocó y cuándo.
• Tema hijo con un style.css vacío o con cabecera incorrecta o incompleta: técnicamente funcional, pero señal de que se creó con prisas.

Tiendas online

Si no hay WooCommerce en la instalación, este bloque no aplica y puedes saltarlo. Si la hay, es igual de importante que cualquiera de los anteriores.

Plantillas de WooCommerce

Cuando un tema a medida copia plantillas de WooCommerce a su propia carpeta woocommerce/, esas plantillas quedan congeladas en la versión de WC que había cuando se programó el tema. Cada actualización de WooCommerce puede cambiar esas plantillas, y si el tema no las actualiza al mismo ritmo, la tienda empieza a comportarse de formas inesperadas y a veces invisibles hasta que el cliente llama.

WooCommerce avisa en WooCommerce > Estado > Herramientas si hay plantillas obsoletas, con la versión de la plantilla original y la que tiene el tema. Si hay plantillas en esa lista, hay trabajo pendiente.

Schema y breadcrumbs de WooCommerce

Si el tema emite su propio schema de producto (JSON-LD o microdata) en las páginas de producto de WooCommerce, entra en conflicto con el que genera el plugin SEO. Uno de los dos debe ganar, y lo razonable es que sea el plugin SEO, no el tema. Revisar el código fuente de una página de producto y buscar bloques <script type="application/ld+json">: si hay más de uno, hay un problema.

Lo mismo con las migas de pan: si el tema tiene los suyos y los de WooCommerce también están activos, el resultado puede ser dos migas de pan en la misma página o ninguna en las páginas de producto.

Crítico

• Acceso directo a pedidos mediante wp_posts o wp_postmeta con post_type='shop_order': desde WooCommerce 7.1, HPOS (High Performance Order Storage) mueve los pedidos a tablas propias. Si el tema consulta pedidos de la forma antigua, falla en cualquier instalación con HPOS activo.
• Uso de $woocommerce->cart, $woocommerce->session u otros accesos directos al global $woocommerce: reemplazados por WC()->cart, WC()->session hace años. Funcionan en instalaciones antiguas, rompen en las nuevas.
• Funciones de WooCommerce eliminadas en versiones recientes: igual que con las funciones de WordPress, si aparecen en el código el tema puede dar error crítico en la próxima actualización mayor de WC.
• Código que llama a funciones de WooCommerce sin comprobar previamente si WC está activo: si WC se desactiva aunque sea temporalmente, el tema da error fatal en lugar de degradar con gracia.

Importante

• Plantillas de WooCommerce sobreescritas con versiones muy por detrás de la actual: el riesgo de rotura es proporcional a la diferencia de versiones.
• Hooks de WooCommerce obsoletos con alias activos: funcionan, pero el alias puede desaparecer en una actualización mayor. Planificar sustitución.
• Assets de WooCommerce desactivados globalmente en el tema cuando solo deberían desactivarse fuera de las páginas de tienda: puede producir carrito roto o checkout sin estilos en algún caso concreto.

Menor

• Plantillas sobreescritas con una o dos versiones de diferencia y sin cambios funcionales conocidos en esas versiones: bajo riesgo inmediato, pero hay que revisarlas en la próxima actualización de WC.

Por dónde empezar

Los tres niveles del artículo trasladan directamente a la priorización del trabajo:

Crítico: corregir antes de entregar, publicar o tocar nada más

No hay entrega válida con críticos abiertos. Si el encargo es asumir el mantenimiento de un proyecto heredado, los críticos se resuelven antes de cualquier otra tarea.

• Vulnerabilidades de seguridad activas: SQL sin preparar, variables sin escapar impresas, ausencia de nonces en formularios que modifican datos.
• Incompatibilidades PHP que pueden dar error crítico con la próxima actualización del servidor.
• Funciones de WordPress o WooCommerce eliminadas del todo.
• Conflictos SEO activos: doble etiqueta <title>, metas duplicadas, meta robots hardcodeado.
• N+1 queries en producción con tráfico real.
• Tema padre comercial modificado directamente sin tema hijo.

Importante: planificar en la próxima actuación

Antes de la siguiente actualización mayor de WordPress o PHP.

• Funciones WP o PHP obsoletas con sustitución conocida.
• Scripts y estilos sin condición que cargan en todas las páginas.
• IDs, slugs y URLs hardcodeados en la lógica del tema.
• APIs de terceros sin fallback documentado.
• Plantillas WooCommerce con varias versiones de diferencia.
• Saltos de jerarquía de encabezados y paginación sin links reales.

Menor: documentar y corregir

Cuando se pase por ese código por otra razón.

• Estilo de código y cumplimiento de estándares de WordPress.
• Cadenas sin traducir, comentarios en el idioma incorrecto, archivos sobrantes.
• Scripts que podrían ir al pie, imágenes sin lazy load.
• Alt de imagen con nombre de archivo, elementos semánticos HTML5 ausentes.

Una vez el tema está limpio y en producción, el escáner de cambios de archivos de Vigilante avisa si alguien modifica un archivo del tema sin que lo sepas, que es exactamente lo que ocurre cuando un ataque planta un backdoor en un archivo que ya existía. No te libra de hacer la auditoría, pero cierra la puerta después de haberla hecho.

Compatibilidad futura

La auditoría que acabas de hacer es una foto del tema en este momento. Un tema bien hecho hoy puede dejar de funcionar en seis meses si nadie vigila lo que viene. Este bloque no es sobre arreglar nada: es sobre no tener que volver a arreglar las mismas cosas en la siguiente revisión porque nadie las anticipó.

PHP

El patrón de PHP es siempre el mismo: lo que hoy es un aviso de obsolescencia, en la siguiente versión mayor desaparece sin más. La lista de lo que PHP 9 va a eliminar ya existe hoy, en forma de avisos de obsolescencia en PHP 8.x. Eso significa que si el tema genera avisos de obsolescencia con PHP 8.5 o con la 8.6 que llega a finales de 2026, esos avisos son exactamente lo que va a romper cuando llegue PHP 9.

PHP 9 no tiene fecha oficial todavía, pero eso no cambia la lógica: las obsolescencias actuales son las eliminaciones futuras. PHPCompatibility te permite pasar como parámetro una versión objetivo futura para que analice el código contra lo que sabe que vendrá. Si aún no tienes configurado PHP CodeSniffer con PHPCompatibility, este es el argumento más práctico para hacerlo.

Para seguir el roadmap de PHP sin tener que buscar manualmente, PHP.Watch mantiene una lista actualizada de todas las versiones en desarrollo, con las obsolescencias y eliminaciones previstas para cada una. Suscribirse a su feed RSS o newsletter es el método más directo de no perderse nada relevante antes de que llegue al servidor.

Lo que hay que comprobar con PHPCompatibility al auditar un tema a medida no es solo la versión de PHP actual del servidor, sino también las siguientes:

• PHP 8.5 (estable desde noviembre de 2025): la versión que muchos hostings tienen como recomendada para 2026.
• PHP 8.6 (prevista para finales de 2026): ya tiene calendario oficial y los primeros RFCs de obsolescencias aprobados.
• PHP 9.x (sin fecha oficial): usar PHPCompatibility en modo --runtime-version=9.0 avisa de lo que ya está marcado como candidato a eliminación en los milestones públicos de php-src.

WordPress

WordPress avisa con antelación de todo lo que deja obsoleto y de todo lo que planea eliminar. El problema es saber dónde mirarlo. Estos son los canales que importan si mantienes un tema a medida:

• Make WordPress Core: el blog de desarrollo del núcleo. Aquí se publican las agendas de los dev chats semanales, los field guides de cada versión y las propuestas de cambios que afectarán a temas y plugins. Si solo sigues un canal, que sea este.
• WordPress Developer Blog: el canal oficial para desarrolladores de plugins y temas. Las dev notes de cada versión se publican aquí con el detalle de qué cambia, qué queda obsoleto y qué hay que actualizar antes de la siguiente mayor.
• Make WordPress Security: el blog del equipo de seguridad. Publica las notas de los problemas resueltos en cada versión puntual y las iniciativas de seguridad del ecosistema.

Ambos blogs tienen feed RSS. Añadirlos al lector de feeds del equipo es suficiente. No hace falta revisar Make Core a diario: las entradas importantes son fáciles de identificar por las etiquetas dev-notes y field-guide.

Para el perfil técnico, el comando wp core check-update de WP-CLI comprueba si hay actualizaciones pendientes del núcleo. Y revisar periódicamente con PHP CodeSniffer + WPCS las funciones del tema contra la versión de WPCS actualizada detecta lo que el equipo de WordPress Core ya ha marcado como deprecated en el estándar, aunque el tema aún funcione hoy sin avisos visibles.

Seguridad

Un tema a medida no está en ninguna base de datos de vulnerabilidades públicas, así que las alertas que importan aquí son las de las librerías de terceros que incluya y las del ecosistema general de WordPress. El 91% de las vulnerabilidades reportadas en WordPress en 2025 estaban en plugins y temas de terceros, no en el núcleo.

Si el tema incluye librerías JavaScript o PHP copiadas en su carpeta, esas librerías sí pueden aparecer en las bases de datos.

Las fuentes que conviene tener activas:

• Patchstack Database: base de datos gratuita de vulnerabilidades en plugins, temas y el núcleo de WordPress. El plan gratuito incluye alertas por email con hasta 48 horas de antelación sobre nuevas vulnerabilidades reportadas. Útil tanto para los plugins de la instalación como para identificar si alguna librería incluida en el tema tiene CVE conocido.
• WPScan Vulnerability Database: base de datos pública con vulnerabilidades de WordPress clasificadas por severidad. Tiene API gratuita para consultas automatizadas y se puede integrar en pipelines de CI/CD.
• WordPress.org Security: las notas oficiales de cada versión de seguridad del núcleo. Feed RSS disponible. Las versiones menores de WordPress (las que tienen tres números, como x.x.1) suelen ser parches de seguridad, y el equipo de WordPress las publica con descripción de lo que corrigen.
• Wordfence Intelligence: el blog de inteligencia de amenazas de Wordfence publica análisis de vulnerabilidades activas, con descripción técnica y estado de explotación. Especialmente útil cuando una vulnerabilidad está siendo explotada masivamente y el tema puede incluir el componente afectado.

WooCommerce

WooCommerce sigue un ciclo de lanzamientos propio, independiente del de WordPress, con versiones mayores que introducen cambios de API y obsolescencia propias. Para mantenerse al día conviene seguir el WooCommerce Developer Blog y revisar el changelog de cada versión mayor antes de actualizar en producción. Las plantillas sobreescritas que ya revisaste en el bloque anterior son exactamente el tipo de deuda que se acumula cuando el mantenedor no sigue ese ritmo.

Periodicidad mínima de revisión

Todo lo anterior tiene sentido si se convierte en un hábito, no en una tarea puntual. Esta es la cadencia mínima razonable para un tema a medida en producción:

• Mensual: revisar las alertas de Patchstack o WPScan para los componentes que incluye el tema. Aplicar las actualizaciones de seguridad pendientes del núcleo y los plugins.
• Con cada versión mayor de WordPress: ejecutar PHP CodeSniffer + WPCS actualizado sobre el tema para detectar lo que la nueva versión ha dejado obsoleto. Revisar las dev notes del Developer Blog antes de actualizar en producción.
• Con cada versión mayor de PHP disponible en el hosting: ejecutar PHPCompatibility contra esa versión en staging antes de cambiarla en producción.
• Anual: repetir la auditoría completa de este artículo. Lo que era Menor el año pasado puede haberse convertido en Crítico si el ecosistema ha avanzado y el tema no.

La IA como herramienta de auditoría: los prompts que más uso

Estos son los prompts prácticos para las revisiones más habituales. No sustituyen al análisis en tiempo de ejecución (Query Monitor, el log de errores) pero cubren gran parte del análisis estático sin instalar nada.

Para el propietario sin código (pegar el contenido de functions.php):

Lee este archivo functions.php y dime en términos simples si hay algo peligroso, algo obsoleto y algo que podría dar problemas de rendimiento. No asumas que sé programar.

Para el análisis SEO (pegar el código fuente HTML completo de la página):

Analiza la estructura de encabezados de este HTML. Dime cuántos H1 hay, si hay saltos de jerarquía y si algún encabezado está en un lugar estructuralmente incorrecto. Busca también si hay más de una etiqueta title o más de una meta description.

Para el técnico (Claude Code sobre la carpeta completa del tema):

Audita este tema WordPress a medida. Busca: 1) vulnerabilidades de seguridad (XSS, SQL injection, ausencia de nonces y de comprobaciones de capacidades); 2) funciones PHP eliminadas o incompatibles con PHP 8.x; 3) funciones WordPress obsoletas; 4) N+1 queries; 5) scripts encolados sin condición en todas las páginas. Clasifica los hallazgos en Crítico, Importante y Menor, y dame el archivo y la línea de cada uno.

Una limitación que hay que tener clara es que la IA detecta problemas en el código estático, no en la ejecución, no rastrea el comportamiento en tiempo real, no ejecuta el tema ni simula una carga real. Es complementaria a Query Monitor y al log de errores, no los reemplaza.

Un regalo para terminar

Y ya que has llegado hasta aquí, para no tener que documentar la auditoría en un Excel improvisado ni en un bloc de notas, hay una herramienta gratuita, la auditoría de temas WordPress, que he creado exactamente para esto.

La abres al lado de lo que estés revisando, vas añadiendo hallazgos con el bloque, la descripción, la gravedad y la acción propuesta, y cuando terminas un botón genera el informe completo listo para exportar, descargar en PDf, imprimir o enviar al cliente. Sin cuenta, sin IA, sin conexión necesaria, todo en tu navegador.

Si tienes dudas sobre lo que encuentres, o quieres apoyo en el mantenimiento continuo de la web una vez resuelta la auditoría, en mi servicio de mantenimiento web tienes la opción de delegar eso. Y para cualquier cosa que no quede clara me tienes en los comentarios.

¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!