Cómo saber si tu WordPress está bien desarrollado

En pocas palabras: Es difícil porque un WordPress mal hecho se ve idéntico a uno bueno desde afuera; la diferencia está en tres señales técnicas que no se ven al navegar: si usa child theme, si carga en menos de 2,5 segundos y si tiene backups y actualizaciones al día.

Para saber cómo identificar la calidad del desarrollo en WordPress no hace falta leer código: mirás tres cosas concretas. Cómo se hicieron las personalizaciones (child theme sí o sí), cuánto tarda en cargar sin excusas del hosting, y si hay backups y actualizaciones al día. Si esas tres fallan, el resto casi siempre también.

El problema es que un WordPress mal hecho se ve igual que uno bien hecho desde afuera. La página abre, el logo está, el formulario manda. La diferencia está abajo del capó, y ahí es donde el 90% de los dueños de sitio nunca mira (hasta que algo explota).

La calidad de desarrollo en WordPress es el conjunto de decisiones técnicas que hacen que un sitio sea mantenible, rápido y actualizable: uso de child themes, respeto por los hooks y filtros del core, código que escapa sus salidas, dependencias documentadas y una base de datos limpia. Un sitio bien desarrollado se actualiza sin romperse; uno mal desarrollado te obliga a llamar al que lo hizo cada vez que WordPress saca una versión nueva.

En 30 segundos

Child theme o nada: si tocaron el theme padre directo, cada update les borra el trabajo. Es la primera señal de amateur.
La lentitud casi nunca es del servidor: plugins pesados, imágenes sin comprimir y falta de caché explican la mayoría de los sitios lentos.
Query Monitor y Lighthouse son gratis: en 5 minutos te dicen qué plugin come recursos y cuánto tarda cada consulta a la base.
Preguntá antes de firmar: «¿usás child themes?» y «¿cómo manejás backups y actualizaciones?» filtran a la mitad de los candidatos.
Un premium bien mantenido le gana a un tema a medida abandonado: la clave no es «custom», es quién lo sostiene después del lanzamiento.

¿Qué señales indican que un WordPress está mal desarrollado?

Las señales de mal desarrollo casi siempre son invisibles en el frontend: modificaciones hechas sobre el theme padre en vez de un child theme, plugins abandonados hace años, el core sin actualizar, funciones metidas a mano en functions.php sin comentar una línea, y una base de datos hinchada de tablas que dejó algún plugin que ya nadie usa. Vos ves un sitio normal; adentro hay una bomba de tiempo. Relacionado: en la comunidad oficial de WordPress.

Hay un patrón que se repite. Ponele que heredás un sitio de otro desarrollador, entrás al panel y ves 34 plugins activos, tres de ellos con la etiqueta roja de «no probado con tu versión de WordPress». Ahí ya sabés cómo viene la mano.

El checklist rápido de banderas rojas:

Tema padre modificado: si editaron style.css o header.php del theme original, la próxima actualización se lleva todo puesto.
Plugins zombis: extensiones sin actualizar hace más de un año, o con el aviso de incompatibilidad. Cada uno es una puerta abierta.
Sin backups automáticos: si el «backup» es que alguien se acuerde de bajar un zip, no hay backup.
Base de datos sin limpiar: revisiones infinitas, transients viejos, tablas huérfanas de plugins que ya no están.
Credenciales por defecto: usuario admin, prefijo wp_ sin tocar, contraseñas débiles.

Ojo con la parte de seguridad. Vulnerabilidades, hardening y malware son un mundo aparte y lo cubrimos en detalle en seguridadenwordpress.com. Acá nos quedamos con lo que hace a la calidad del código y la arquitectura.

¿Por qué tu WordPress es lento y casi nunca es el hosting?

La mayoría de los sitios WordPress lentos no tienen un problema de servidor, tienen un problema de cómo están armados. Plugins de redes sociales que cargan scripts externos en cada página, un analytics mal configurado que dispara tres pedidos, imágenes de 4000px pesando 2 MB, y ninguna capa de caché. Cambiar de hosting no arregla nada de eso.

¿Cómo lo diagnosticás sin adivinar? Con Query Monitor ves cuántas consultas hace cada página a la base de datos y cuál plugin las genera. Con Lighthouse (viene integrado en Chrome, tecla F12, pestaña Lighthouse) medís los Core Web Vitals reales: LCP, CLS e INP, la métrica de interactividad que reemplazó a FID en marzo de 2024. Si el LCP se va arriba de 2,5 segundos, tenés trabajo.

Eso sí: el hosting importa cuando la base de la casa es buena. De nada sirve optimizar imágenes si el servidor tarda un segundo y medio solo en responder (el famoso TTFB). Si vas a probar caché con LiteSpeed, asegurate de que tu proveedor lo soporte de verdad; el hosting WordPress de Donweb trae LSCache nativo, por ejemplo, así no dependés solo de un plugin.

¿Cómo identificar calidad de desarrollo WordPress en el código sin ser programador?

Revisar la calidad del código sin ser dev es posible si sabés qué mirar. No necesitás leer PHP línea por línea: necesitás detectar si el desarrollador respetó las reglas del ecosistema. Las tres preguntas técnicas que importan son si usó child theme, si sigue los WordPress Coding Standards y si el código toca el core a través de hooks y filters en vez de editar archivos del núcleo.

Lo que un desarrollador serio hace y uno improvisado no:

Usa hooks y filters: extiende WordPress con add_action y add_filter, nunca edita archivos del core. Si tocás wp-includes, perdés todo en el próximo update.
Escapa las salidas: funciones como esc_html() o esc_url() antes de imprimir datos. Es la diferencia entre un sitio prolijo y uno con agujeros.
Verifica nonces: los formularios y acciones AJAX validan un token contra pedidos falsos.
Documenta dependencias: un README, comentarios en functions.php, un changelog. Si nadie documentó nada, la deuda técnica ya empezó a correr.
Corre PHP_CodeSniffer con el ruleset WPCS: es la herramienta oficial para auditar estilo y errores comunes de forma automática.

Un truco de no-programador: pedile al dev que te muestre la carpeta del child theme. Si existe, tiene functions.php con comentarios y las plantillas están separadas por tipo, buena señal. Si te dice «no, lo hice directo sobre el theme para ir más rápido», ahí tenés tu respuesta.

Tema a medida vs tema premium: ¿cuál habla mejor del desarrollo?

Un tema premium bien usado le gana a un tema a medida mal mantenido, casi siempre. La calidad no está en la palabra «custom», está en quién lo sostiene después del lanzamiento. Un premium de un autor activo recibe actualizaciones, tiene documentación y una comunidad que reporta bugs. Un tema a medida sin contrato de mantenimiento es deuda técnica pura: el día que el dev desaparece, quedás con un theme que nadie más entiende.

Criterio	Tema a medida	Tema premium bien mantenido
Documentación	Depende del dev (a veces cero)	Manual completo y foros
Actualizaciones	Solo si hay contrato	Regulares, incluidas
Soporte	Una sola persona	Equipo + comunidad
Riesgo si el dev se va	Alto: nadie lo entiende	Bajo: código estándar
Cuándo conviene	Necesidad muy específica + contrato firme	El 80% de los proyectos

calidad desarrollo wordpress diagrama explicativo

¿Significa que nunca vale la pena un tema a medida? No. Cuando tenés una necesidad que ningún premium resuelve y un acuerdo de mantenimiento post-launch en papel, un desarrollo a medida es lo correcto. El error es pagar un custom «para tener algo único» y después dejarlo huérfano.

¿Qué herramientas gratuitas sirven para evaluar un sitio WordPress?

Con herramientas gratis podés auditar un WordPress en menos de 15 minutos sin instalar casi nada. Cada una mide algo distinto: rendimiento, plugins detectados, SEO técnico o salud interna del sitio. La clave es cruzar los resultados, porque una sola nunca te da la foto completa. Cubrimos ese tema en detalle en probar cambios en un ambiente seguro.

Herramienta	Qué mide	Cómo la leés
Google Lighthouse	Rendimiento, SEO, accesibilidad	Score sobre 100 + Core Web Vitals
GTmetrix	Tiempos de carga y TTFB	Waterfall de qué recurso frena
Salud del sitio (nativo WP)	Versión de PHP, plugins, config	Panel en Herramientas > Salud
Query Monitor (plugin)	Consultas a la base y hooks	Qué plugin genera más queries
Wappalyzer	Theme y plugins que usa el sitio	Detecta el stack sin acceso al panel
WAVE	Accesibilidad	Errores de contraste y etiquetas

Empezá por la herramienta de Salud del sitio, que WordPress trae de fábrica desde la versión 5.2. Te dice al toque si estás corriendo una versión vieja de PHP (un clásico de sitios mal mantenidos) o si hay plugins inactivos ocupando lugar.

¿Qué preguntas hacerle a un desarrollador WordPress antes de contratarlo?

Las preguntas correctas filtran a un profesional de un improvisado en cinco minutos. No preguntes «¿sabés WordPress?» (todos dicen que sí). Preguntá por el método de trabajo, que es donde se nota el oficio.

¿Usás child themes o modificás el tema directo? La respuesta correcta es child theme, sin dudar.
¿Cómo manejás backups y actualizaciones? Buscás un proceso, no un «me fijo cuando puedo».
¿Seguís los WordPress Coding Standards? Un sí con ejemplo concreto vale más que un sí a secas.
¿Documentás el código? Sin documentación, el próximo dev arranca de cero.
¿Qué plan de mantenimiento ofrecés post-launch? El lanzamiento es el principio, no el final.
¿Me pasás referencias de clientes anteriores? Y llamalos, no te quedes con el link.

Subís un requerimiento, el dev te promete todo, firmás, arranca el trabajo, y a los dos meses descubrís que «documentación» para esa persona era un archivo de texto con tres líneas y que el mantenimiento se cobra aparte a un valor que nunca mencionó. Por eso las preguntas van antes de firmar, no después.

Errores comunes al evaluar la calidad de un WordPress

Juzgar por el frontend: que se vea lindo no dice nada del código. Un sitio prolijo puede estar podrido adentro. Corregilo mirando plugins, updates y child theme.
Confundir «muchos plugins» con «completo»: 40 plugins no es potencia, es superficie de fallas. Cada uno es código de terceros que puede romperse.
Echarle la culpa al hosting sin medir: antes de migrar, corré Lighthouse y Query Monitor. Casi siempre el culpable está en tu propia instalación.
Creer que «a medida» es sinónimo de calidad: un custom sin mantenimiento envejece peor que un premium actualizado.
No pedir el acceso completo: si el dev no te da usuario admin y acceso al hosting, no es tu sitio, es el suyo.

Preguntas Frecuentes

¿Cómo sé si mi desarrollador WordPress es bueno?

Un buen desarrollador WordPress usa child themes, sigue los Coding Standards oficiales, documenta el código y arma un plan de backups y actualizaciones. Si extiende el sitio con hooks y filters en vez de editar archivos del core, y te da acceso completo al panel y al hosting, estás en buenas manos. En revisar y reparar enlaces rotos profundizamos sobre esto.

¿Cómo auditar un sitio WordPress sin ser técnico?

Corré Google Lighthouse desde Chrome (F12) para el rendimiento, instalá Query Monitor para ver qué plugins pesan, y entrá a Herramientas > Salud del sitio, que WordPress trae de fábrica. En 15 minutos tenés una foto clara sin escribir una sola línea de código.

¿Por qué mi WordPress es lento si tengo buen hosting?

La lentitud suele venir del propio sitio, no del servidor: plugins pesados, imágenes sin comprimir, scripts externos y falta de caché. Antes de culpar al hosting, medí con Lighthouse y Query Monitor cuál recurso frena la carga. Un servidor rápido no compensa una instalación mal armada.

¿Qué es un child theme y por qué importa tanto?

Un child theme es un tema hijo que hereda todo del theme padre pero guarda tus modificaciones aparte. Importa porque cuando el theme padre se actualiza, tus cambios sobreviven. Editar el theme padre directo es la señal número uno de desarrollo amateur: cada update borra el trabajo.

¿Conviene un tema a medida o uno premium?

Para el 80% de los proyectos, un tema premium bien mantenido conviene más que un desarrollo a medida, porque tiene actualizaciones, soporte y documentación. El tema a medida solo vale la pena ante una necesidad muy específica y con un contrato de mantenimiento post-launch firmado.

Conclusión

Identificar calidad de desarrollo en WordPress se reduce a mirar debajo del capó, no la carrocería. Child theme, velocidad medida con datos reales, backups al día y código que respeta el core: esas cuatro cosas te dicen más que cualquier demo pulida. Y lo mejor es que casi todo lo verificás con herramientas gratis en una tarde.

Si vas a contratar, hacé las preguntas antes de firmar y pedí acceso completo. Si ya tenés el sitio andando, corré Lighthouse y Query Monitor esta semana. Cuando la base técnica está bien armada, recién ahí un buen hosting termina de exprimir el rendimiento, y no al revés.