Checklist SEO tras actualizar WordPress: qué revisar

Un checklist SEO tras actualizar WordPress es una lista corta de cosas que verificar en la web en producción después de actualizar el núcleo, un tema o un plugin: meta robots, titles, canonicals, el sitemap, el robots.txt y los tags de tracking. Conviene revisar el SEO después de cada actualización porque las actualizaciones sustituyen archivos y migran ajustes, y la parte visible suele verse idéntica mientras el markup de debajo ha cambiado.

Este artículo trata la hora siguiente a una actualización. Para los ajustes que merece la pena vigilar todo el año, consulta monitorización SEO en WordPress, y para un cambio de dominio o de plataforma, el checklist SEO para migraciones web.

Actualizaciones de plugins SEO: plantillas de título, robots por defecto y sitemap

Yoast SEO y Rank Math construyen los titles a partir de plantillas con variables. Yoast las escribe como %%title%% %%sep%% %%sitename%% y Rank Math como %title% %sep% %sitename%. Cuando una plantilla se restablece, o una variable deja de resolverse, el resultado aparece a la vez en el <title> de todas las URL de ese tipo de contenido. Lo que hay que buscar es un title que diga literalmente "%%sitename%%" o que haya perdido el nombre de la página.

Los mismos plugins controlan la meta robots de archivos, etiquetas, páginas de autor y URL de adjuntos multimedia. Una migración de ajustes en una versión mayor puede cambiar esos valores por defecto, así que compara la <meta name="robots"> de un archivo de etiqueta o de autor con la que tenía antes.

Después abre el índice del sitemap. Los dos plugins lo sirven en /sitemap_index.xml, y cada uno tiene un interruptor que lo desactiva (en Rank Math, el módulo Sitemap; en Yoast, la función de sitemaps XML). Si el índice devuelve un 404, o ha desaparecido de él un tipo de contenido, Search Console seguirá leyendo el envío antiguo y más adelante informará de errores. La pérdida de entradas del sitemap se trata con más detalle en páginas eliminadas del sitemap.

Actualizaciones de temas que sobrescriben header.php

Actualizar un tema sustituye sus archivos por la copia del proveedor. Todo lo que se editó directamente en el tema padre, en lugar de en un tema hijo, se pierde. En muchas webs antiguas eso incluye un snippet de GTM pegado en header.php o una meta etiqueta de verificación añadida a mano.

El fallo más grave es que falte la llamada a wp_head(). Los plugins inyectan su salida a través de ese hook, así que si una plantilla de cabecera personalizada deja de llamarlo, desaparecen a la vez el title, la descripción, el canonical y las etiquetas robots del plugin SEO, junto con lo que añadan Site Kit o un plugin de GTM. La página se sigue mostrando. Mira el código fuente, busca el canonical y, si no está, comprueba si también falta el bloque de comentarios del plugin SEO.

Actualizaciones de page builders y H1

Elementor, Divi y constructores similares guardan los encabezados como widgets con un ajuste de etiqueta HTML. Una actualización que cambie una plantilla global, una cabecera del theme builder o la forma en que el tema muestra su propio título de página puede dejar una página con dos H1 o sin ninguno. Un ejemplo habitual es un tema que empieza a imprimir el título de la entrada como H1 encima de un diseño del builder que ya tiene el suyo. Revisa el H1 de la home, de una landing y de una entrada.

Plugins de caché y optimización que mueven GTM

WP Rocket, LiteSpeed Cache, Autoptimize y plugins similares pueden diferir, retrasar o combinar JavaScript. Tras una actualización, un nuevo valor por defecto o una lista de exclusiones distinta puede dejar el contenedor de GTM detrás de una regla de "retrasar hasta la interacción del usuario". El tag sigue en el HTML, así que la revisión del código fuente sale bien, pero dejan de enviarse las páginas vistas de los visitantes que nunca hacen scroll ni clic.

Ayudan dos hábitos. Purga la caché de páginas después de cada actualización, porque el HTML que ves con la sesión iniciada normalmente se la salta. Después carga la página en una ventana privada con la pestaña Red abierta y confirma que la petición a gtm.js se lanza antes de interactuar. Los pasos para GA4 están en cómo comprobar que GA4 está instalado.

Enlaces permanentes, robots.txt y subidas desde staging

Los plugins que registran tipos de contenido o taxonomías personalizados pueden cambiar sus reglas de reescritura en una actualización. Hasta que las reglas se regeneran, esas URL devuelven 404 mientras las páginas normales funcionan. Entrar en Ajustes > Enlaces permanentes y pulsar Guardar cambios las regenera, igual que wp rewrite flush en WP-CLI. Prueba una URL de cada tipo de contenido personalizado en lugar de darlo por hecho.

El robots.txt necesita su propia revisión. Si no hay un archivo físico, WordPress sirve uno virtual que los plugins SEO pueden editar, y una actualización de plugin o una importación de ajustes pueden reescribirlo sin que cambie ningún archivo en el disco. Si hay un archivo físico, ese es el que manda, y un despliegue puede copiar encima una versión de staging con Disallow: /.

Las subidas desde staging son el momento en que el ajuste "Visibilidad en los motores de búsqueda" sorprende a mucha gente. La opción se guarda en la base de datos, así que subir la base de datos de un staging con "Disuadir a los motores de búsqueda de indexar este sitio" marcada añade noindex a toda la web en producción. Cómo detectar un noindex en producción repasa las formas de detectarlo.

Checklist SEO de 10 minutos tras actualizar WordPress

Hazlo en el dominio en producción, sin sesión iniciada y con la caché purgada.

1. Confirma que la home y una página interior devuelven 200 y no muestran el aviso de mantenimiento programado ("Briefly unavailable for scheduled maintenance").
2. Mira el código fuente de la home, de una entrada y de una página de categoría, y busca noindex.
3. Ejecuta curl -I sobre la home y comprueba que no hay una cabecera X-Robots-Tag que no esperabas.
4. Compara el <title> y la meta description de esas páginas con los que tenían antes de la actualización.
5. Comprueba que cada página tiene un solo H1 y que es el que esperas.
6. Confirma que el canonical está presente y apunta a la propia URL de la página, con el protocolo y el host correctos.
7. Abre /sitemap_index.xml (o /wp-sitemap.xml si no hay plugin SEO) y comprueba que siguen apareciendo todos los tipos de contenido.
8. Abre /robots.txt y compáralo con la versión anterior.
9. Visita una URL por cada tipo de contenido y taxonomía personalizados y confirma que ninguna devuelve 404.
10. En una ventana privada, confirma que cargan GTM, GA4 y el Meta Pixel, y que el banner de cookies sigue apareciendo.

Guarda una copia del robots.txt y de algunos titles antes de actualizar. Sin un "antes", la mayoría de estas comprobaciones se convierten en conjeturas.

Qué automatizar y qué seguir haciendo a mano

Hacer esto en un sitio tras una actualización planificada es realista. Hacerlo en treinta webs de clientes en las que los plugins se actualizan solos de madrugada no lo es, porque a menudo ni sabes que se ha ejecutado una actualización.

Deltio cubre la parte automática. Lee el sitemap y las páginas de cada sitio una vez al día, los compara con la comprobación anterior y envía alertas por Slack y email para ese sitio cuando cambian el noindex, el robots.txt, los canonicals, los titles, las meta descriptions, los H1 o las URL del sitemap, cuando faltan GA4, GTM, el Meta Pixel o la plataforma de consentimiento de cookies, o cuando una página de mantenimiento sustituye al contenido. También controla el uptime y la caducidad de SSL y dominio.

Al ser diario, te avisa al día siguiente de una actualización automática que ha roto algo. Para una actualización que lanzas tú, sigue pasando el checklist en el momento, o lanza un escaneo SEO manual en Deltio en cuanto hayas purgado la caché.

Si quieres tener cubiertas las actualizaciones nocturnas, hay una prueba gratuita de 14 días.