SEO en WordPress: qué configurar de verdad (y qué dejar en paz) en 2026

El SEO en WordPress no se arregla instalando un plugin: se arregla sabiendo qué hace el núcleo por su cuenta, qué deja abierto y qué no depende del CMS en absoluto. Esta guía separa esas tres cosas.

WordPress no es un gestor de contenido de nicho. Según W3Techs (31-oct-2026), lo usa el 39,5% de todas las webs y el 58,2% de las que tienen un CMS identificable. Dentro de WordPress, el 67,7% ya corre la rama 7 y la versión estable es la 7.1.4. Cualquier guía que presente "WordPress 6" como el presente está desactualizada.

Lo que WordPress ya hace solo (y lo que no hace en absoluto)

Antes de tocar nada, conviene saber qué está resuelto. Desde la 5.5 el núcleo publica un índice de sitemaps en /wp-sitemap.xml y lo declara solo en robots.txt. Desde la 5.7 añade max-image-preview:large, la directiva que permite a Google mostrar miniaturas grandes en resultados y en Discover. Desde la 5.5 aplica carga diferida y desde la 6.3 marca con fetchpriority="high" la imagen que detecta como LCP.

Lo que ningún ajuste del núcleo te da

El núcleo no escribe meta descriptions, no emite ni un dato de schema y no genera hreflang para contenido multilingüe. Tampoco pone canonical fuera de las páginas individuales, incluidos tus archivos. Son cuatro huecos grandes, y son los que un plugin SEO tapa.

Por qué "instala un plugin SEO" es la respuesta incompleta

Un plugin resuelve esa capa, pero no cambia el hosting, no desmarca el interruptor de visibilidad ni arregla una plantilla que carga cinco tipografías. Si comparas opciones, la guía de plugins SEO para WordPress cubre esa parte; aquí vamos a la configuración técnica.

El interruptor que deja una web entera fuera de Google

En Ajustes > Lectura existe una casilla llamada "Disuadir a los motores de búsqueda de indexar este sitio". Mucha gente la comprueba en robots.txt y se queda tranquila. Es un error de diagnóstico: desde la versión 5.3 ese check no toca robots.txt, sino que imprime <meta name='robots' content='noindex,nofollow' /> en el <head>, siempre que el tema llame a wp_head(). Solo hasta la 5.2 escribía Disallow: / en el archivo de robots.

Las tres comprobaciones de 60 segundos

Primero, el código fuente: abre la home, busca "noindex" y confirma que no aparece. Segundo, la cabecera de la respuesta por consola. Tercero, una búsqueda site:tudominio.com en Google: si no devuelve ni la portada, hay algo cerrando la puerta.

curl -s https://tudominio.com/ | grep -i "noindex"
curl -sI https://tudominio.com/ | head -15

El caso clásico es una web lanzada con la casilla marcada, tres meses de silencio y la conclusión de que "Google no indexa". Se desmarca, se pide indexación de la home y en pocos días el sitio entra. Si vienes de un staging clonado, revisa ese check el primer día.

Sitemaps: el del núcleo, el del plugin y el que sobra

El índice de la 5.5 aguanta hasta 50.000 sitemaps y cada sitemap incluye un máximo de 2.000 URLs, filtrable con wp_sitemaps_max_urls. Genera entradas para cada tipo de contenido y taxonomía públicos, para la portada y también para los archivos de autor. Con eso, la mayoría de las webs no necesita un sitemap externo.

El detalle que casi nadie mira: no hay lastmod

El sitemap del núcleo no incluye lastmod, y el índice no lo admite en ningún caso. Se añade con un filtro sobre la entrada de cada post. Los límites, el formato y cuándo conviene usar sitemaps de imagen o vídeo ya están en la guía de índices de sitemap y lastmod.

add_filter( 'wp_sitemaps_posts_entry', function( $entry, $post ) {
    $entry['lastmod'] = get_post_modified_time( 'c', true, $post );
    return $entry;
}, 10, 2 );

El sitemap de autores que no necesitas

En una web de un solo autor, ese sitemap solo añade URLs de archivo y expone el nombre de usuario del panel. Se elimina sin plugins con el hook wp_sitemaps_add_provider, devolviendo false cuando el proveedor es users. Y si tu plugin SEO también genera un sitemap, revisa cuál declaras en robots.txt: dos con el mismo contenido son ruido tolerable; con contenidos distintos, mandan señales contradictorias.

Páginas que WordPress crea y que no deberían competir por tus keywords

El archivo de etiqueta lista los mismos posts que la categoría; el de fecha, los mismos que el blog; el de autor, lo mismo. Google elige una versión y el resto queda como contenido duplicado. Deja indexables solo los archivos que aportan algo propio (una categoría con texto de introducción) y aplica noindex al resto.

Adjuntos: desde la 6.4 las instalaciones nuevas los redirigen, las antiguas no

Las páginas de adjunto no aportan información útil, pero existían, se indexaban y a veces rankeaban con resultados malos para el usuario. La 6.4 las desactivó en instalaciones nuevas. El matiz importante: en los sitios existentes la opción se pone a 1 al actualizar, así que siguen vivas. Se controlan con wp_attachment_pages_enabled.

Búsquedas internas y paginación de comentarios

?s= genera páginas de resultados que nadie revisó y que pueden indexarse; ?replytocom multiplica URLs del mismo post. Los dos se resuelven con Disallow en robots.txt o con un canonical hacia la página del post. Si tu archivo de robots necesita repaso, la guía de robots.txt en 2026 tiene las directivas y los errores frecuentes.

Canonical: el hueco que el núcleo deja abierto

La función rel_canonical() del núcleo empieza con if ( ! is_singular() ) { return; }. Es literal: solo emite canonical en consultas individuales. Archivos, blog, resultados de búsqueda y paginación se quedan sin etiqueta canonical, y eso no es un bug, es el alcance que WordPress eligió.

Cómo comprobarlo sin instalar nada

curl -s https://tudominio.com/etiqueta/ejemplo/ | grep -i canonical

Si no devuelve nada, no hay canonical en ese archivo. Un plugin SEO lo añade; un tema rara vez lo hace bien. Y si añades canonical a mano en la plantilla, cuida la paginación: la página 2 de una categoría no debe apuntar a la página 1, porque la estás sacando del índice.

Rendimiento: lo que ya está resuelto y lo que sigue pesando

Desde la 6.3 el núcleo marca la imagen LCP con prioridad alta y nunca aplica loading="lazy" a esa misma imagen: combinar las dos cosas es un antipatrón que la propia documentación de WordPress señala. Los datos de campo de aquella versión mostraron entre un 16% y un 21% de mejora de LCP en móvil en sitios que cargaban su imagen principal en diferido, y algo incómodo: la detección de la imagen LCP acierta cerca del 50% de las veces.

Speculative loading desde la 6.8

La precarga especulativa viene activa salvo con login o con permalinks desactivados, y dispara el prefetch cuando el usuario empieza a hacer clic, un criterio conservador. Excluye por defecto las URLs con parámetros y se ajusta con wp_speculation_rules_configuration y wp_speculation_rules_href_exclude_paths. No la pases a prerender sin auditar carritos y formularios: no es lo mismo que el prefetch de los resource hints.

Lo que ningún ajuste del núcleo arregla

Hosting y TTFB, versión de PHP, caché de objetos, imágenes y fuentes. Si el LCP es malo por el servidor, ningún checkbox lo mueve. Para servidor, hosting y SEO; para formatos, WebP y AVIF.

Plugins, temas y el orden correcto para tocar todo esto

Un plugin SEO, no dos. Dos plugins que escriben title, meta description y schema se pisan: gana el que se ejecuta último y el resultado cambia con cada actualización. Decide quién es dueño de cada cosa (titles, meta, schema, sitemap, canonical, redirecciones) y deja el resto apagado. El tema, por su parte, no debería emitir sus propias meta etiquetas si ya hay un plugin encargado.

El orden que funciona: visibilidad e indexación, permalinks, sitemap y robots, archivos que no deben indexarse, canonical, datos estructurados y, al final, rendimiento. Actualizar el núcleo a 7.1.4 va primero en la lista de cualquier mes: una web comprometida pierde indexación más rápido de lo que la recupera.

Auditoría de 12 puntos para tu SEO en WordPress

Doce comprobaciones:

1. El código fuente no contiene noindex en la portada.
2. robots.txt declara el sitemap correcto y no bloquea recursos necesarios.
3. Los permalinks son legibles y estables.
4. El sitemap responde 200 y lista tus URLs publicadas.
5. Archivos de etiqueta, autor y fecha: indexables o no, pero decidido.
6. Páginas de adjunto desactivadas si tu instalación las arrastra.
7. Hay canonical en archivos y en la paginación apunta a sí misma.
8. Una sola fuente de titles y meta descriptions.
9. Schema presente en artículos y en la organización.
10. La imagen LCP no lleva loading="lazy".
11. La versión del núcleo está al día.
12. Search Console sin acciones manuales ni cobertura rara.

El orden de ataque: interruptor de visibilidad y robots.txt el día uno, porque pueden estar costando la web entera; archivos y canonical el día dos; rendimiento y contenido después. Para seguir por enlaces internos y páginas sueltas, los artículos de enlazado interno y de páginas huérfanas son el paso siguiente.