6 min de lectura
Respuesta breve
WordPress no necesita un plugin distinto para cada tarea SEO. Empieza por inventariar lo que resuelven Core, el tema, el servidor y los plugins activos. Conserva una única fuente para metadatos y schema, añade dependencias solo con una necesidad concreta y valida siempre la salida pública, no solo la pantalla de ajustes.
Puntos clave
- WordPress Core ya aporta tipos, URLs, feeds y sitemaps.
- El tema debe encargarse de presentación, no de datos persistentes.
- Una suite SEO puede ser válida si evita duplicidades y tiene owner.
- Dos plugins activos pueden emitir canonicals o schema incompatibles.
- Rendimiento y mantenibilidad se miden; no se deducen del número de plugins.
- Cada cambio necesita instalación limpia, upgrade, caché y rollback.
Índice
- Por qué “menos plugins” no es la única regla
- Inventario por responsabilidades
- Qué resuelve WordPress Core
- Qué pertenece al tema
- Qué justifica un plugin SEO
- Detectar conflictos
- Rendimiento y seguridad
- Proceso para retirar o sustituir un plugin
- Ejemplo hipotético
- Errores frecuentes
- Preguntas habituales
Por qué “menos plugins” no es la única regla
Un plugin bien mantenido puede resolver una necesidad compleja mejor que código propio. Un fragmento pegado sin pruebas puede ser más arriesgado que una dependencia. La pregunta correcta no es cuántos plugins existen, sino qué responsabilidad tiene cada uno, qué salida produce y quién lo mantiene.
La sobrecarga aparece cuando varias capas hacen lo mismo, cargan recursos globales o introducen funcionalidad que no se utiliza. También cuando nadie sabe qué componente controla canonical, schema, sitemap o redirecciones.
Inventario por responsabilidades
Construye una tabla:
| Capa | Función | Salida pública | Owner | Prueba |
|---|---|---|---|---|
| Core | posts, taxonomías, URLs, feeds, sitemap | HTML/XML | equipo WordPress | integración |
| tema | plantillas, navegación, imágenes | HTML/CSS/JS | frontend | visual/a11y |
| plugin SEO | metadatos, schema, controles | head/JSON-LD | SEO/técnico | crawler |
| plugin funcional | eCommerce, idiomas, forms | rutas y scripts | producto | E2E |
| servidor/CDN | caché, compresión, headers | respuesta HTTP | operaciones | readback |
Añade versión, licencia, estado de mantenimiento, peso, dependencias y plan de retirada. Un plugin sin función concreta se convierte en candidato de revisión, no de eliminación inmediata.
Qué resuelve WordPress Core
Core ofrece el modelo de contenido, revisiones, APIs, title support, canonical en ciertos contextos, feeds y un sistema de sitemaps extensible. El anuncio oficial de sitemaps (RS-011) documenta el índice /wp-sitemap.xml.
Esto no significa que Core cubra toda estrategia. Significa que una solución propia debe extenderlo conscientemente. Por ejemplo, el artículo de sitemap XML explica cómo validar tipos y URLs antes de instalar otro generador.
Qué pertenece al tema
El tema controla HTML semántico, componentes, navegación, assets y presentación. Debe funcionar sin un plugin propietario activo, utilizando fallbacks Core. No debería registrar CPT, procesar formularios ni guardar opciones SEO persistentes: cambiar de diseño no debe borrar el dominio.
Para páginas comerciales, una plantilla de código reduce desviación. El editor de bloques puede seguir disponible para artículos con una lista limitada. Esta separación no es estética: facilita probar y sustituir cada capa.
Qué justifica un plugin SEO
Una suite SEO puede aportar controles editoriales, canonicals, Open Graph, schema, sitemaps y migraciones. Conservarla puede ser la decisión más segura si está instalada, licenciada y configurada. Crear una capa propia también puede ser razonable para un alcance estrecho.
En ambos casos define una sola fuente de verdad. SEONIDAS plantea un modo automático: si detecta una suite conocida, desactiva solo sus salidas duplicadas y muestra diagnóstico; nunca elimina o desactiva el tercero sin autorización.
Los datos estructurados siguen el contenido visible. La política oficial (RS-008) no respalda añadir tipos o propiedades inventadas para obtener una feature.
Detectar conflictos
Inspecciona el HTML de varias plantillas:
- más de un canonical;
- titles o descriptions duplicados;
- varios grafos JSON-LD incompatibles;
- dos sitemaps activos;
- robots emitido por meta y cabecera con valores opuestos;
- Open Graph con hosts o imágenes diferentes;
- redirecciones en plugin y servidor;
- assets cargados en páginas donde no se usan.
Comprueba también admin y REST con roles distintos. Una ruta visible no demuestra permisos correctos. El servicio de auditoría SEO integra estas evidencias con prioridad.
Rendimiento y seguridad
No atribuyas lentitud a “muchos plugins” sin perfilar. Mide consultas, tiempo PHP, memoria, HTML, requests, CSS y JavaScript por plantilla. Un plugin pequeño puede hacer una llamada remota en cada request; uno grande puede cargar condicionalmente.
Revisa actualizaciones, advisories, privilegios, nonces, sanitización, escape y endpoints. No instales una dependencia recomendada por una web sin validar nombre, propietario, licencia y mantenimiento. Mantén plugins y temas desde fuentes fiables.
El SEO técnico relaciona rendimiento con rastreo y experiencia. La solución no consiste en retirar CSS de bloques a ciegas y romper artículos.
Proceso para retirar o sustituir un plugin
- inventaría funciones y datos que posee;
- exporta configuración mediante un método seguro;
- captura HTML, sitemap y rutas antes del cambio;
- prepara equivalencias y migración de meta si hace falta;
- prueba en una copia o staging;
- desactiva y valida páginas, admin, cron y CLI;
- purga caché y lee la superficie pública;
- conserva rollback y no borres datos durante la primera fase;
- elimina solo con autorización y evidencia de que no se necesita.
Una desactivación limpia es distinta de un uninstall destructivo.
Ejemplo hipotético
Un sitio utiliza una suite SEO y un tema que imprime su propio canonical. Se instala además un plugin de schema. El crawl detecta dos canonicals y dos entidades Organization con datos distintos. La corrección no exige reemplazar todo: se elige la suite como fuente, se retira la salida del tema y se desactiva el tipo duplicado del plugin de schema tras comprobar plantillas.
Es un escenario sintético, no un caso de cliente ni un resultado medido.
Errores frecuentes
- Instalar otro plugin para corregir un conflicto de plugins.
- Desactivar una suite sin migrar sus metadatos.
- Añadir snippets al tema padre.
- Validar solo la portada.
- Medir rendimiento una sola vez y sin caché declarada.
- Eliminar revisiones o datos para “optimizar” sin backup.
- Desactivar REST, cron o embeds de forma global sin saber quién los usa.
- Confiar en una puntuación del admin sin revisar HTML.
- Incluir herramientas de desarrollo en el ZIP de producción.
Preguntas habituales
¿Necesito Yoast, Rank Math u otra suite?
Depende del alcance y la instalación. Una suite madura puede ser adecuada. Lo importante es evitar duplicidades, conocer sus datos y mantenerla. La decisión no se toma por orgullo técnico.
¿Un plugin siempre hace más lenta la web?
Todo código tiene coste, pero el impacto varía. Mide su comportamiento por request y plantilla. El número por sí solo no diagnostica.
¿Puedo hacer SEO solo con Core?
Core ofrece una base, pero un proyecto puede necesitar controles editoriales, schema o diagnósticos adicionales. Añade la capa mínima con tests y documentación.
¿Dónde deben vivir los CPT?
En un plugin o funcionalidad persistente, no en el tema. Así el contenido permanece al cambiar de diseño.
Conclusión
Una instalación WordPress mantenible no persigue cero plugins; persigue responsabilidades claras, una salida coherente y dependencias justificadas. Inventariar y probar cada capa suele resolver más que añadir otra interfaz.
Próximo paso
Construye la matriz Core–tema–plugin–servidor y revisa HTML, sitemap y assets de tres plantillas. Si necesitas un diagnóstico completo, consulta SEO WordPress y auditoría SEO antes de retirar componentes.