# Auditoría SEO WordPress: qué revisar y corregir primero

> Auditoría SEO en WordPress: visibilidad en buscadores, conflictos de plugins SEO, sitemap, archivos, adjuntos, tema, velocidad y rastreadores de IA.

URL: https://seorecheck.com/es/blog/wordpress-seo-audit-guide · Publicado: 2026-10-16 · [English](https://seorecheck.com/blog/wordpress-seo-audit-guide.md), [Українська](https://seorecheck.com/ua/blog/wordpress-seo-audit-guide.md)

Una **[auditoría SEO](https://seorecheck.com/es/blog/what-is-an-seo-audit) de WordPress** es una revisión de un sitio WordPress que analiza los problemas propios de este CMS (los ajustes de visibilidad en buscadores, lo que imprimen los plugins SEO, los archivos generados automáticamente, las páginas de adjuntos, el marcado del tema y el exceso de plugins), además de las comprobaciones habituales de rastreo, indexación y contenido. El objetivo es una lista corta de correcciones ordenadas por prioridad, empezando por todo lo que bloquee la indexación.

WordPress mueve una parte enorme de la web, y la mayoría de sus problemas de SEO vienen de los ajustes por defecto, los plugins y los temas, no del núcleo del software. Esta guía explica qué revisar, dónde suele fallar WordPress y qué corregir primero.

## ¿Por qué un sitio WordPress necesita su propia auditoría SEO?

Un sitio WordPress necesita una auditoría específica porque el CMS crea URLs, etiquetas y archivos que nunca escribiste a mano. Los archivos de etiquetas, las páginas de autor, las páginas de adjuntos, un robots.txt virtual y un sitemap generado automáticamente vienen de serie. Después, los plugins y el tema añaden su propio código encima.

Una auditoría general sigue siendo necesaria. Necesitas lo básico de nuestra guía de [auditoría SEO técnica](https://seorecheck.com/es/blog/technical-seo-audit): rastreabilidad, indexación, redirecciones y velocidad. Pero en WordPress la causa de un hallazgo suele ser un ajuste o un plugin, así que la solución es marcar una casilla, cambiar de plugin o cambiar de tema. Rara vez hace falta tocar código.

Los hallazgos típicos en WordPress son estos:

- Todo el sitio está en `noindex` porque se quedó marcada una casilla después del lanzamiento.
- Dos plugins SEO imprimen cada uno su propia canonical y su propia meta description.
- Cientos de páginas de etiquetas con poco contenido están indexadas.
- Las páginas de adjuntos de imágenes aparecen en los resultados en lugar de las entradas.
- Un tema basado en maquetador (page builder) carga JavaScript pesado y no supera las Core Web Vitals.

## Checklist SEO para WordPress: qué revisar primero

Revisa en orden de impacto. Si Google no puede indexar el sitio, nada de lo que viene después importa todavía.

| Prioridad | Comprobación | Dónde mirar en WordPress | Solución habitual |
|---|---|---|---|
| 1 | Visibilidad en los motores de búsqueda | Ajustes → Lectura | Desmarcar «Disuadir a los motores de búsqueda» |
| 2 | Reglas de robots.txt | `/robots.txt`, plugin SEO, archivo en el servidor | Quitar bloqueos de CSS/JS y rutas importantes |
| 3 | Sitemap | `/wp-sitemap.xml` o el sitemap del plugin | Una sola fuente de sitemap, solo con URLs indexables |
| 4 | Etiquetas SEO duplicadas | Código fuente: canonical, title, meta | Quedarte con un solo plugin SEO |
| 5 | Archivos y adjuntos | Etiquetas, autores, fechas, medios | Noindex o desactivar los archivos pobres |
| 6 | Canonicals y redirecciones | Enlaces permanentes, HTTP→HTTPS, www | Un único salto 301 hacia la URL canónica |
| 7 | Tema y renderizado | Encabezados, contenido en el HTML | Corregir plantillas, evitar contenido solo en JS |
| 8 | Rendimiento | Plugins, imágenes, hosting, caché | Eliminar plugins sin uso, optimizar el LCP |
| 9 | Datos estructurados | Schema que genera el plugin | Un grafo limpio de Organization y Article |
| 10 | Acceso de rastreadores de IA | robots.txt, plugins de seguridad, CDN | Permitir los bots que quieras |

Para la lista completa, válida para cualquier plataforma, consulta el [checklist de auditoría SEO](https://seorecheck.com/es/blog/seo-audit-checklist). Las secciones siguientes explican los puntos específicos de WordPress.

## ¿Está bloqueando tu sitio el ajuste «Disuadir a los motores de búsqueda»?

Revisa esto lo primero. Cuando está marcada la opción **Ajustes → Lectura → Disuadir a los motores de búsqueda de indexar este sitio**, WordPress imprime una etiqueta meta robots `noindex,nofollow` en todas las páginas. Según la [documentación de los ajustes de Lectura de WordPress](https://wordpress.org/documentation/article/settings-reading-screen/), así funciona desde la versión 5.3. Antes, WordPress servía en su lugar un robots.txt con `Disallow: /`.

Esta casilla suele marcarse en el sitio de pruebas (staging) y se arrastra al pasar a producción. El resultado: un sitio publicado que nunca aparece en Google. La misma documentación aclara que la opción es solo una petición, así que no sirve para mantener privado un entorno de pruebas. Para eso, usa protección con contraseña.

El ajuste también desactiva los sitemaps del núcleo de WordPress. El [anuncio de los sitemaps de WordPress 5.5](https://make.wordpress.org/core/2020/07/22/new-xml-sitemaps-functionality-in-wordpress-5-5/) indica que los sitemaps del núcleo respetan la opción de «disuadir a los motores de búsqueda». Así que si `/wp-sitemap.xml` no devuelve nada en un sitio sin plugin SEO, esta casilla es lo primero que hay que sospechar.

**Cómo verificarlo:** abre cualquier página, mira el código fuente y busca `name="robots"`. Después pasa algunas URLs clave por la herramienta de inspección de URLs de Search Console.

## ¿Cómo se audita el robots.txt y el sitemap en WordPress?

WordPress sirve un robots.txt virtual salvo que exista un archivo real en la raíz del sitio, y los plugins SEO pueden editarlo. Abre `/robots.txt` en el navegador y lee lo que realmente se sirve. No te fíes de lo que diga la pantalla de ajustes del plugin.

Qué buscar:

- **Recursos del tema o de plugins bloqueados.** Un consejo antiguo recomendaba bloquear `/wp-content/` o `/wp-includes/`. La [introducción a robots.txt de Google](https://developers.google.com/search/docs/crawling-indexing/robots/intro?hl=es) advierte contra bloquear recursos que los rastreadores necesitan para entender la página. El CSS y el JS dentro de `/wp-content/` suelen entrar en ese grupo.
- **Usar robots.txt para ocultar páginas.** Google afirma que robots.txt «no es un mecanismo para impedir que una página web aparezca en Google». Las URLs bloqueadas pueden indexarse igualmente, sin descripción. Nuestra [guía de robots.txt](https://seorecheck.com/es/blog/robots-txt-seo-guide) explica las reglas en detalle.
- **Disallow y noindex en la misma URL.** La [documentación de Google sobre noindex](https://developers.google.com/search/docs/crawling-indexing/block-indexing?hl=es) indica que una página con `noindex` no debe estar bloqueada por robots.txt, porque si no, Googlebot nunca ve la directiva.

Un robots.txt seguro y típico de WordPress se ve así:

```
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.com/wp-sitemap.xml
```

### Comprobaciones del sitemap

El núcleo de WordPress genera sitemaps en `/wp-sitemap.xml` desde la versión 5.5. Incluyen los tipos de contenido públicos, las taxonomías, los archivos de autor y la página de inicio, con hasta 2000 entradas por archivo de sitemap por defecto ([anuncio del núcleo de WordPress](https://make.wordpress.org/core/2020/07/22/new-xml-sitemaps-functionality-in-wordpress-5-5/)). Los plugins SEO pueden desactivar el sitemap del núcleo y servir el suyo propio.

Qué auditar:

1. **Una sola fuente de sitemap**, y que sea la que está enviada en Search Console y referenciada en robots.txt.
2. **Ninguna URL con noindex, redirigida o con error 404** dentro del sitemap. Un caso habitual: los archivos de etiquetas están en noindex pero siguen apareciendo en el sitemap.
3. **Ningún tipo de contenido vacío o privado** (formularios, plantillas del maquetador, contenido de membresía) expuesto como entrada del sitemap.

## ¿Qué páginas de WordPress generan contenido duplicado y pobre?

WordPress crea automáticamente varios tipos de páginas de archivo. Muchas repiten contenido que ya está en otra parte o contienen solo una o dos entradas. De ahí sale la mayor parte del exceso de páginas indexadas (index bloat) en WordPress.

| Tipo de página | URL de ejemplo | Problema habitual | Decisión habitual |
|---|---|---|---|
| Archivos de etiquetas | `/tag/blue-widgets/` | Cientos de etiquetas, una entrada cada una | Noindex, o fusionar etiquetas en categorías |
| Archivos de autor | `/author/admin/` | Duplican el blog en sitios con un solo autor | Noindex o desactivar |
| Archivos por fecha | `/2024/03/` | Duplicación pura | Noindex o desactivar |
| Páginas de adjuntos | `/photo-123/` | Una página que solo contiene una imagen | Redirigir al archivo o a la entrada padre |
| Archivos paginados | `/blog/page/7/` | Normalmente bien | Mantener rastreables, con canonical a sí mismos |
| Búsqueda interna | `/?s=term` | URLs pobres infinitas | Noindex, sin enlazarlas |

Las páginas de adjuntos merecen una revisión más detallada en sitios antiguos. En WordPress 6.4, el núcleo añadió la opción `wp_attachment_pages_enabled`. Según la [nota sobre páginas de adjuntos de WordPress 6.4](https://make.wordpress.org/core/2023/10/16/changes-to-attachment-pages/), viene desactivada por defecto en las instalaciones nuevas, así que las páginas de adjuntos redirigen al archivo. Los sitios que ya existían antes de la actualización mantienen esas páginas activadas. Por eso un sitio antiguo puede tener todavía miles de URLs con solo una imagen que Google puede indexar. Informes de Search Console como [Rastreada: actualmente sin indexar](https://seorecheck.com/es/blog/crawled-currently-not-indexed-fix) suelen llenarse de estas URLs.

Los archivos de categorías son otra cosa. Una página de categoría bien escrita, con una introducción y una selección cuidada de entradas, puede posicionar, así que dale contenido real y mantenla indexable.

## ¿Hay dos plugins SEO peleándose por tus etiquetas?

Es uno de los hallazgos más comunes en WordPress. Dos plugins SEO (o un plugin SEO más un tema con funciones SEO integradas) imprimen cada uno un title, una meta description, una canonical y marcado schema. La página acaba con dos canonicals o con dos etiquetas `og:` contradictorias.

La [guía de Google sobre consolidación de URLs duplicadas](https://developers.google.com/search/docs/crawling-indexing/consolidate-duplicate-urls?hl=es) advierte expresamente contra indicar canonicals distintas para la misma página mediante métodos diferentes, y pide usar URLs absolutas. Si el código fuente de una página muestra dos líneas `rel="canonical"`, ya has encontrado el problema. Quédate con un solo plugin SEO, desactiva las funciones SEO del tema y vuelve a comprobarlo. Para las reglas generales de canonicalización, consulta la [guía de la etiqueta canonical](https://seorecheck.com/es/blog/canonical-tag-guide).

Ya que estás en el código fuente, revisa también:

- **Plantillas de title y meta.** Plantillas como `%title% | %sitename%` están bien. Que falten plantillas y todas las fichas de producto se llamen «Tienda | Marca», no.
- **Que las canonicals apunten a la URL final**: HTTPS, la versión correcta con o sin www y el mismo estilo de barra final que tus enlaces permanentes.
- **Canonicals de la paginación.** La página 2 de un archivo debe tener canonical a sí misma, no a la página 1.

## ¿Cómo afectan los temas y los maquetadores al SEO de WordPress?

El tema controla tu HTML: la estructura de encabezados, si el contenido principal está en el HTML inicial y cuánto CSS y JavaScript carga cada página. Dos sitios con los mismos plugins pueden obtener resultados muy distintos solo por el tema.

Qué auditar:

- **Un único H1 por página, con el título de la página.** Algunos temas envuelven el logo en un H1 en todas las páginas, o ponen los títulos de las entradas como H2.
- **Contenido en el HTML sin procesar.** Las pestañas, acordeones y sliders que cargan el texto solo después de ejecutarse JavaScript pueden ocultarlo a los rastreadores que no renderizan las páginas. Compara el código fuente con lo que ves en el navegador.
- **Enlaces internos en etiquetas `<a href>` reales.** Los megamenús y los botones de «cargar más» hechos con eventos de JavaScript suelen dejar huérfanas las entradas profundas. Consulta [enlazado interno para SEO](https://seorecheck.com/es/blog/internal-linking-seo-guide).
- **Restos del contenido de demostración.** Las demos importadas con el tema dejan páginas de ejemplo, elementos de portfolio y entradas «¡Hola, mundo!» en el índice.

## ¿Por qué son lentos los sitios WordPress y qué hay que revisar?

En WordPress, las páginas lentas suelen deberse a demasiados plugins, maquetadores pesados, imágenes sin optimizar y hosting sin caché de páginas. Mide primero: consulta los datos de campo de Core Web Vitals en Search Console o en PageSpeed Insights, ya que los umbrales (LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1) se aplican al percentil 75 de las visitas reales. Nuestra [guía de Core Web Vitals](https://seorecheck.com/es/blog/core-web-vitals-guide) explica cada métrica.

Causas propias de WordPress que conviene buscar:

- **Plugins que cargan recursos en todas las páginas.** Un script de formulario de contacto, slider o popup que se carga en las 500 entradas cuando solo lo usa una página.
- **Una imagen de cabecera grande como elemento LCP**, sin precarga y, a veces, con carga diferida (lazy load) por error.
- **Sin caché de páginas**, de modo que cada visita ejecuta PHP y consultas a la base de datos.
- **Varios plugins de optimización a la vez**, que pueden romper la minificación de los demás y provocar desplazamientos de diseño.
- **Elementos incrustados de terceros** (widgets de chat, carruseles de reseñas) que ralentizan la interacción y empeoran el INP.

Elimina antes de optimizar. Desactivar tres plugins que no usas suele aportar más que ajustar diez opciones.

## ¿Qué debe revisar una auditoría de WordPress para la búsqueda con IA?

En WordPress, las comprobaciones para la búsqueda con IA se reducen sobre todo a acceso y claridad. ¿Pueden los rastreadores de IA acceder a tus páginas, está el texto principal en el HTML y está el negocio claramente identificado en los datos estructurados? WordPress añade sus propios riesgos: los plugins de seguridad y los ajustes de bloqueo de bots de la CDN pueden bloquear a los rastreadores de IA sin que nadie se dé cuenta.

Revisa estos puntos:

- **Reglas de robots.txt y del firewall** para los bots de búsqueda y de entrenamiento de IA. Un plugin de seguridad puede bloquear bots que robots.txt permite.
- **Marcado Organization con enlaces `sameAs`** a tus perfiles oficiales, impreso una sola vez por tu plugin SEO.
- **Controles de fragmentos** como `nosnippet` o `max-snippet` que un plugin ha aplicado por error a todo el sitio.

El [checklist de optimización para búsqueda con IA](https://seorecheck.com/es/blog/ai-search-optimization-checklist) recoge los rastreadores documentados de cada plataforma. Para comprobar estos puntos en tu propio sitio, una [auditoría gratuita de SEORecheck](https://seorecheck.com/es/request) informa de los ajustes de indexación, las etiquetas duplicadas y los problemas de sitemap y archivos descritos arriba, además del acceso de los rastreadores de IA en robots.txt, los controles de fragmentos, el texto visible solo con JavaScript y el marcado Organization/sameAs.

## ¿Cómo se priorizan las correcciones SEO en WordPress?

Corrige en este orden: primero lo que bloquea la indexación, después las señales duplicadas, luego el exceso de páginas indexadas, después la velocidad y, por último, el contenido y los datos estructurados. Un sitio en noindex no gana nada con imágenes más rápidas. Un sitio con 3000 páginas de etiquetas pobres gana más limpiándolas que reescribiendo una meta description.

Un plan práctico:

1. **Días 1–30:** ajuste de visibilidad en buscadores, robots.txt, un único sitemap, un solo plugin SEO, corrección de canonicals y redirecciones.
2. **Días 31–60:** noindex o eliminación de los archivos pobres, redirección de las páginas de adjuntos, limpieza del contenido de demostración, corrección de los encabezados del tema.
3. **Días 61–90:** limpieza de plugins y Core Web Vitals, enlazado interno, datos estructurados y acceso de los rastreadores de IA.

Después, vuelve a auditar el sitio para confirmar que cada problema está realmente resuelto. El [informe de ejemplo](https://seorecheck.com/es/sample) muestra cómo es un plan priorizado, y la [comparativa de la reauditoría](https://seorecheck.com/es/sample/compare) muestra cómo se siguen los problemas resueltos, mejorados, sin resolver y nuevos tras un segundo rastreo.

## Conclusiones clave

- Empieza cualquier auditoría SEO de WordPress por **Ajustes → Lectura** y el robots.txt publicado. Una sola casilla puede desindexar todo el sitio.
- Quédate con **un solo plugin SEO** y una sola fuente de sitemap. Las canonicals y metaetiquetas duplicadas vienen de conflictos entre plugins y tema.
- Las páginas de etiquetas, autor, fecha y adjuntos son la principal fuente de **exceso de páginas indexadas** en WordPress. Los sitios antiguos pueden tener aún activadas las páginas de adjuntos.
- Nunca combines `Disallow` y `noindex` en la misma URL. Google no puede ver un noindex en una página que no tiene permiso para rastrear.
- Los problemas de velocidad suelen venir de plugins, maquetadores e imágenes. Elimina lo que no usas antes de ajustar cualquier otra cosa.
- Comprueba que los plugins de seguridad y los ajustes de la CDN no bloquean a los rastreadores de IA que quieres permitir.

---

## ¿Quieres saber qué corregir en tu web?

Obtén una vista previa gratuita de la auditoría SEO: tu puntuación y problemas reales, con evidencias de tus páginas.

- [Recibir vista previa gratis](https://seorecheck.com/es/request)
- [Ver informe de ejemplo](https://seorecheck.com/es/sample)
