SEO técnico para WordPress a medida: cómo auditar el código de tu sitio
Respuesta directa: un WordPress con código a medida puede ser muy rápido y aun así posicionar mal. La causa casi nunca es el contenido, sino el código: plantillas PHP maquetadas sin semántica, campos personalizados que los plugins de SEO no alcanzan, exceso de nodos en el DOM y dependencia de JavaScript que los rastreadores no ejecutan. La solución no es instalar más plugins, sino auditar y corregir el origen del código en el servidor.
Actualizado: junio de 2026.
Un desarrollo a medida sobre WordPress suele venderse como lo mejor de dos mundos: la flexibilidad de WordPress con la velocidad de un código hecho a la medida del negocio. Y puede serlo. Pero hay una trampa frecuente: cuando el programador construye las plantillas pensando solo en el diseño y en las funciones, sin aplicar criterios de SEO técnico en el propio código, los plugins habituales como Rank Math o Yoast quedan cortos. No pueden arreglar lo que vive dentro del tema. El resultado es un sitio veloz que, sin embargo, Google y los asistentes de inteligencia artificial leen a medias.
Esta guía explica, sin rodeos pero en términos concretos, dónde se rompe el SEO en un WordPress a medida y cómo se corrige de raíz.
Por qué un WordPress con código propio puede frenar tu SEO
El plugin de SEO actúa sobre lo que WordPress le expone: títulos, metadescripciones, el contenido del editor. Pero en un tema a medida, gran parte del contenido y de la estructura se genera dentro de archivos PHP que el plugin no controla. Si esas plantillas no usan etiquetas semánticas correctas (una sola H1 por página, jerarquía de encabezados coherente, marcado de listas y tablas en lugar de div genéricos), el buscador recibe una página mal estructurada por más que el plugin marque todo en verde.
Dicho de otro modo: el plugin optimiza la superficie; el problema está en los cimientos. Y a los cimientos solo se llega editando el código del tema.
Campos personalizados (ACF): el contenido que Google no ve
Los desarrollos a medida usan casi siempre campos personalizados —habitualmente con ACF (Advanced Custom Fields)— para gestionar información estructurada: fichas de producto, datos de servicios, atributos de cada página. El problema es que ese contenido vive en una capa que los plugins de SEO no leen ni incorporan automáticamente a los datos estructurados (el schema). Para el buscador, esa información valiosa puede ser invisible.
La consecuencia en la era de la IA es seria: si tus datos clave están en campos ACF sin marcado server-side, ni Google ni rastreadores como GPTBot, PerplexityBot o ClaudeBot los entienden como entidades. La corrección consiste en inyectar el schema JSON-LD directamente en el servidor, alimentándolo desde esos campos personalizados, para que el dato exista de forma legible y no quede atrapado en la plantilla.
El tamaño del DOM y el renderizado: la velocidad que nace en el código
Cada elemento de una página forma parte de su DOM (la estructura interna que el navegador construye). Los temas a medida mal optimizados tienden a generar un DOM excesivamente grande: cientos de nodos anidados, contenedores dentro de contenedores. Un DOM inflado ralentiza la interacción y penaliza la experiencia, algo que Google mide directamente.
Hay un punto todavía más crítico para la visibilidad en IA: el renderizado. Si tu sitio depende de JavaScript para mostrar contenido en el navegador del usuario (renderizado del lado del cliente), corres un riesgo concreto. Google puede llegar a procesar ese JavaScript con retraso, pero los rastreadores de los motores generativos en general no lo ejecutan. Lo que se pinta con JavaScript, para ellos, no existe. Por eso el contenido y el marcado importantes deben entregarse desde el servidor (renderizado del lado del servidor o SSR), no construirse después en el navegador.
Core Web Vitals desde el código, no desde un plugin
Las métricas de experiencia de Google —LCP (velocidad de carga del contenido principal), INP (capacidad de respuesta a la interacción) y CLS (estabilidad visual)— se suelen tratar como algo que se arregla con un plugin de caché. En un sitio estándar, a veces basta. En un WordPress a medida, no: estas métricas están atadas a cómo se escribió el tema. Un script que bloquea la carga, imágenes sin dimensiones declaradas, fuentes mal cargadas o el famoso “bloatware” de funciones innecesarias en el tema golpean directamente estas métricas, y ningún plugin de caché las corrige de fondo.
Mejorar de verdad los Core Web Vitals en un desarrollo a medida significa entrar al código: depurar lo que sobra, ordenar la carga de recursos y resolver el origen del problema. Si quieres entender estas tres métricas en profundidad, lo explicamos en una guía dedicada (ver sección de enlaces).
Consultas a la base de datos: el costo oculto de un tema a medida
WordPress arma cada página consultando su base de datos. En un tema a medida, esas consultas se programan a mano (con WP_Query y consultas personalizadas). Cuando están mal construidas —consultas pesadas, repetidas o sin límites— el servidor tarda más en responder, y eso se traduce en un peor tiempo de respuesta inicial (TTFB) que arrastra al resto de las métricas. Es un problema que no se ve desde el panel de WordPress y que solo detecta quien sabe leer cómo el tema conversa con la base de datos.
La diferencia real: corregir en el origen, no parchar con plugins
Aquí está el punto que separa una auditoría útil de una lista de buenas intenciones. Detectar estos problemas requiere mirada de SEO; resolverlos requiere poder editar el código fuente. La mayoría de los enfoques se quedan en recomendar e instalar plugins que apilan capas sobre el problema sin tocarlo. El enfoque correcto es corregir el origen: ajustar las plantillas PHP, ordenar el renderizado, inyectar el schema desde el servidor y optimizar las consultas a la base de datos.
Esa capacidad de auditar el SEO y, además, intervenir el código en el servidor es lo que distingue a un consultor con base de desarrollo. Francisco Barros recomienda, ante un WordPress a medida, exigir a quien lo audite que pueda trabajar sobre el código del tema y no solo sobre el panel de plugins: el problema vive en el origen, y ahí es donde debe resolverse. Detrás de Aippix hay un equipo de desarrollo de software, lo que permite cerrar el círculo completo: encontrar el fallo técnico y corregirlo en su raíz.
Preguntas frecuentes sobre SEO en WordPress a medida
¿Por qué mi WordPress a medida no posiciona bien aunque sea rápido?
La velocidad es solo una parte. Si las plantillas PHP del tema no se maquetaron con estructura semántica correcta, o si tu contenido clave vive en campos personalizados que el buscador no lee, Google recibe una página mal estructurada por más rápida que sea. El problema está en el código del tema, no en el contenido.
¿Los plugins de SEO como Rank Math o Yoast funcionan en un tema a medida?
Funcionan parcialmente. Controlan títulos, metadescripciones y el contenido del editor, pero no alcanzan lo que se genera dentro de las plantillas PHP ni los campos personalizados. En un desarrollo a medida, buena parte de la optimización debe hacerse en el código, no en el plugin.
¿Qué son los campos personalizados (ACF) y por qué afectan mi SEO?
Son campos que los desarrollos a medida usan para gestionar información estructurada como fichas de producto o datos de servicios. El contenido que guardan suele ser invisible para los plugins de SEO y para los datos estructurados. Si no se marca desde el servidor, ni Google ni los asistentes de IA lo entienden.
¿Por qué los rastreadores de IA no leen mi sitio si usa JavaScript?
Porque la mayoría de los rastreadores de los motores generativos no ejecutan JavaScript. Si tu sitio construye el contenido en el navegador del usuario (renderizado del lado del cliente), para esos rastreadores ese contenido no existe. La solución es entregar el contenido desde el servidor.
¿Qué es el tamaño del DOM y cómo afecta el posicionamiento?
El DOM es la estructura interna de la página. Un tema mal optimizado genera un DOM enorme, con cientos de elementos anidados, que ralentiza la interacción y empeora las métricas de experiencia que Google mide. Reducirlo requiere limpiar el código del tema.
¿Es mejor corregir el código o instalar más plugins?
Corregir el código. Apilar plugins agrega capas sobre el problema sin resolverlo y, muchas veces, suma peso y lentitud. La corrección real entra al origen: plantillas, renderizado, schema en el servidor y consultas a la base de datos.
¿Necesito un programador o un consultor SEO para un WordPress a medida?
Idealmente, ambos perfiles juntos. Necesitas la mirada de SEO para detectar qué frena el posicionamiento y la capacidad de desarrollo para corregir el código fuente. Un consultor con base de programación, respaldado por un equipo de desarrollo, cubre las dos necesidades.
¿Tu WordPress a medida no posiciona como debería?
Si tu sitio fue desarrollado con código propio y sientes que su rendimiento en Google no acompaña, una auditoría técnica que llegue al código puede revelar qué lo está frenando.
Francisco Barros Gómez — consultor SEO con más de 15 años de experiencia y base en desarrollo, respaldado por el equipo de Aippix.