Auditoría de rendimiento y seguridad web: qué revisa y cuánto cuesta

Tu sitio carga despacio, un aviso de un plugin o un nombre desconocido en tu lista de usuarios te ha inquietado, y quieres que un solo equipo lo revise todo, lo arregle y se quede contigo. Ese equipo existe. Lo primero que debería darte es una auditoría de rendimiento y seguridad web: una revisión escrita que cubre velocidad y riesgo a la vez, ordena lo que hay que arreglar y pone precio al trabajo.

Este artículo te cuenta quién puede hacer ese trabajo, qué revisa la auditoría y qué suele fallar en WordPress, Webflow, Shopify y Next.js. También explica cuánto cuesta arreglarlo, cómo confirmar que funcionó y cómo conservar los avances.

No necesitas leer código para seguirlo. Necesitas un objetivo (más consultas, menos carritos abandonados, ningún incidente) y una visión honesta de cómo está hoy el sitio.

Quién puede hacer una auditoría de rendimiento y seguridad web#

Necesitas un equipo responsable que audite el sitio, arregle lo que encuentre y lo mantenga después. Cuando esos trabajos están repartidos entre proveedores distintos, los huecos entre ellos pasan a ser tu trabajo. Ahí es donde los sitios lentos y expuestos suelen seguir igual.

Tres tipos de proveedor que encontrarás#

La mayoría de compradores se topa con tres tipos de proveedor. Un proveedor solo de seguridad busca malware y vulnerabilidades conocidas y envía un informe. Un especialista solo en velocidad ajusta imágenes, caché y scripts. Un único equipo se encarga de la auditoría, los arreglos y el mantenimiento.

Los dos primeros tienen su lugar. Una limpieza puntual de malware encaja con un proveedor de seguridad, y una sola página de campaña encaja con un especialista en velocidad. Se quedan cortos cuando la causa es compartida. Un especialista en velocidad que quita un plugin pesado puede no enterarse de que además tenía una vulnerabilidad conocida.

Por qué una auditoría cubre velocidad y seguridad#

Los sitios lentos y expuestos suelen compartir causas. Un plugin que nadie actualizó pesa más que su versión actual y además es una puerta de entrada habitual. Un script de seguimiento añadido por marketing retrasa la primera pantalla y ejecuta código que nadie de tu equipo revisó. Un hosting económico sin reglas de caché a menudo tampoco tiene firewall ni una copia de seguridad probada.

Cuando un mismo equipo lo lee todo de una vez, encuentra cada causa una vez y la arregla una vez. Recibes un informe, una lista de prioridades y una persona a quien llamar. Eso suele ser más barato y más claro que dos proyectos que deshacen el trabajo del otro.

Qué preguntar antes de contratar#

Haz estas preguntas en la primera llamada. Las respuestas dicen más que una lista de precios.

• ¿Recibiré un informe escrito, con los hallazgos ordenados por riesgo y esfuerzo?
• ¿La velocidad se mide con visitantes reales o solo en una prueba de laboratorio?
• ¿Trabajan en mi plataforma cada semana o una vez al año?
• ¿Quién toca el sitio después de la auditoría y con qué rapidez responde?
• ¿Cómo demostraremos juntos que el arreglo funcionó?
• ¿Qué pasa si una actualización rompe algo?

Si además estás decidiendo entre un freelance y una agencia para el mantenimiento, freelance o agencia para el mantenimiento web compara ambos en riesgo y continuidad.

Qué revisa una auditoría de rendimiento y seguridad web#

Una auditoría de rendimiento y seguridad web es una revisión estructurada de la rapidez con que tu sitio responde a visitantes reales y de lo expuesto que está a los problemas que suelen causar incidentes. Recibes un informe que lista cada hallazgo, por qué importa a tu negocio, cuánto esfuerzo requiere y en qué orden actuar. Cubre seis áreas, agrupadas abajo en cuatro partes.

Core Web Vitals con visitantes reales#

Las Core Web Vitals son las medidas de Google de cómo percibe un visitante una página. LCP es la rapidez con que aparece el contenido principal. INP es la rapidez con que la página responde a un toque o un clic. CLS es cuánto se mueve el diseño mientras carga. web.dev explica cada métrica, y Google describe cómo encajan en la experiencia de página.

La auditoría lee datos de campo, es decir, mediciones de visitantes reales en móviles reales, y los compara con los umbrales siguientes.

Una prueba de laboratorio ayuda a encontrar causas, mientras que los datos de campo te dicen si los visitantes notan el problema. Para el detalle de las métricas, lee cómo dominar las Core Web Vitals en sitios B2B.

Inventario de plugins, temas y dependencias#

El auditor lista todo lo que ejecuta tu sitio: plugins, tema, apps, scripts incrustados y librerías de código. De cada uno anota la versión, la fecha de la última actualización y su función. Todo lo que no se usa, está desactualizado o abandonado queda marcado.

Es la fuente más rápida tanto de mejoras de velocidad como de menos riesgo. El OWASP Top 10 cita los componentes vulnerables y desactualizados como una de sus principales categorías de riesgo, y cada plugin sin usar suma además peso a tus páginas.

Servidor, cabeceras y certificados#

A continuación la auditoría revisa la configuración del hosting: la versión de PHP o Node, la caché, la compresión, el certificado y la CDN (una red que sirve los archivos desde un lugar cercano al visitante). También lee las cabeceras de respuesta que envía tu sitio. Strict-Transport-Security mantiene a los navegadores en la versión segura de tu sitio, y Content-Security-Policy limita qué scripts pueden ejecutarse en tus páginas.

Las cabeceras ausentes y los ajustes por defecto entran en la categoría de configuración de seguridad incorrecta, otra categoría general de OWASP. Son hallazgos frecuentes y a menudo se arreglan rápido.

Copias de seguridad y accesos#

La última área decide lo malo que puede ser un mal día. La auditoría comprueba con qué frecuencia se hacen las copias, dónde se guardan (una copia en el mismo servidor no cuenta) y cuándo se restauró una por última vez. Después lista quién tiene acceso de administrador, si antiguos empleados o agencias aún lo conservan y si el inicio de sesión en dos pasos está activado.

El control de acceso roto figura entre las principales categorías de OWASP, y en equipos pequeños suele ser algo simple: una cuenta antigua que nadie cerró. El informe convierte las cuatro partes en una lista ordenada. Es el comienzo de un ciclo, porque los hallazgos se arreglan por orden, luego se vigilan y después se vuelven a leer en la siguiente auditoría.

Ciclo de auditoría

1. 01AuditarVitals, inventario, servidor, copias y accesos
2. 02PriorizarOrden por riesgo y esfuerzo
3. 03ArreglarMejoras rápidas y luego estructura
4. 04MantenerMonitorización e informe mensual

Siguiente auditoría

Ciclo de cuatro etapas: auditar, priorizar, arreglar y mantener, con la monitorización alimentando la siguiente auditoría

Causas comunes de sitios lentos e inseguros por plataforma#

La plataforma determina dónde se esconden los problemas. En Webflow y Shopify el proveedor se ocupa del hosting y del núcleo, así que los problemas vienen sobre todo de lo que añades. En WordPress y en las apps a medida tu equipo es dueño de más piezas, así que importan más las actualizaciones y los ajustes del hosting.

WordPress y WooCommerce#

La cantidad y la antigüedad de los plugins son la historia habitual. Cada plugin puede cargar scripts y estilos en todas las páginas, y cada uno es código que alguien debe mantener actualizado. Las tiendas WooCommerce añaden consultas de carrito y checkout, que necesitan reglas de caché que respeten a los compradores con sesión iniciada y un host dimensionado para el tráfico.

Webflow#

El hosting y la CDN están gestionados, así que las lentitudes suelen venir de imágenes grandes, muchas fuentes y embeds de código personalizado para chat, seguimiento y formularios. El riesgo de seguridad está en ese código de terceros incrustado, en quién tiene acceso de Editor y de Designer, y en los formularios que envían datos a otras herramientas.

Shopify#

Las apps añaden scripts al tema, y algunas dejan código tras desinstalarlas. Las secciones pesadas del tema, las imágenes sin dimensiones y los muchos píxeles de seguimiento ralentizan la página de producto. Shopify gestiona el checkout, así que la auditoría se centra en las cuentas del personal con permisos totales, las apps con acceso amplio a datos y el código del tema.

Next.js y apps a medida#

Los problemas de velocidad vienen de enviar demasiado JavaScript al navegador y de peticiones de datos que nada cachea. El riesgo viene de dependencias desactualizadas, rutas de API que no comprueban quién pregunta, secretos guardados en el lugar equivocado y cabeceras ausentes en la capa de hosting. El código a medida te da la mayor libertad y exige el cuidado más regular.

Cómo ordenar los arreglos: primero las mejoras rápidas#

Trabaja en este orden: primero contén el riesgo, luego toma las mejoras de velocidad que cuestan menos horas y después haz el trabajo estructural. El sitio se mantiene seguro mientras mejora y ves resultados visibles pronto.

Primera semana: contener el riesgo#

Estos pasos son pequeños, baratos y te protegen más. Prueba cada uno en una copia de staging (un duplicado privado del sitio) antes de tocar el sitio en vivo.

1. Haz una copia de seguridad nueva y guarda otra copia fuera del servidor.
2. Elimina las cuentas de administrador de quienes se fueron y activa el inicio de sesión en dos pasos.
3. Actualiza los componentes con vulnerabilidades conocidas.
4. Borra los plugins, apps y scripts que nadie usa.
5. Confirma que HTTPS funciona en todas las páginas y que el certificado se renueva solo.

Mejoras rápidas que mueven las métricas#

La mayoría de las mejoras de velocidad salen de una lista corta. Redimensiona las imágenes y sírvelas en un formato moderno, cargando más tarde las que están bajo la primera pantalla. Activa la caché y la compresión. Aplaza o elimina los scripts de terceros que no justifican su peso. Define ancho y alto en imágenes y embeds para que el diseño deje de saltar.

Algunas de ellas suelen mover LCP y CLS en pocos días, porque atacan lo que el visitante espera primero. El trabajo más pesado, como las consultas lentas a la base de datos o el código del tema, viene después.

Cuándo conviene rehacer el sitio#

Parchear tiene un límite. Rehacer el sitio es la respuesta honesta cuando el tema o el código ya no se mantiene, cuando cada arreglo rompe otra cosa o cuando la plataforma no puede hacer lo que el negocio necesita ahora. También encaja cuando un año de parches costaría casi lo mismo que una construcción nueva.

La mayoría de los sitios no llega a ese punto, y una buena auditoría lo dice con las cifras al lado. Si llegas, al menos decides con evidencia y no con frustración.

Cuánto cuesta una auditoría de rendimiento y seguridad web#

El coste sigue al esfuerzo, y el esfuerzo sigue a lo que se ha acumulado en tu sitio. Toma cualquier cifra de aquí como punto de partida para tu propio presupuesto, porque el tamaño, la plataforma y el estado la cambian.

Qué sube o baja el precio#

Seis cosas mueven más el precio:

• Tamaño: páginas, productos, idiomas e integraciones que revisar.
• Componentes: cuántos plugins, apps y dependencias hay, y qué antigüedad tienen.
• Hosting: si el sitio debe pasar a una configuración mejor.
• Código a medida: código de tema o de app que hay que leer y cambiar.
• Estado: un sitio limpio cuesta menos que uno ya infectado.
• Pruebas: una copia de staging y pruebas del checkout suman tiempo y evitan sorpresas.

Un ejemplo práctico, claramente ilustrativo#

Imagina un sitio B2B en WordPress con unas 40 páginas. Supón que ejecuta 22 plugins, seis de ellos desactualizados y tres sin usar, no tiene cabeceras de seguridad, guarda las copias solo en el mismo servidor y aún lista a dos antiguos empleados como administradores. El LCP móvil en datos de campo está por encima del objetivo de 2,5 segundos.

Los rangos de abajo son ilustrativos para un sitio típico de este tamaño y no son un presupuesto. Tu estimación escrita sale de la propia auditoría.

En este ejemplo, la auditoría más las mejoras rápidas quedarían en la mitad inferior de esas dos filas. El trabajo estructural solo aparece si el informe muestra que las mejoras rápidas no bastan.

Arreglo puntual o plan mensual#

Un arreglo es un proyecto y el mantenimiento es un ritmo. Los plugins publican actualizaciones cada semana, los certificados caducan y se añaden scripts nuevos, así que un sitio reparado vuelve a deteriorarse si nadie lo vigila. Elige un proyecto puntual (Small, Medium, Large o Custom) para el arreglo, y un plan mensual Care o un Retainer para lo que sigue.

Las opciones de contratación muestran cómo funciona cada una. Un plan mensual suele costar menos que recuperarse de un solo incidente, y hace tu presupuesto predecible.

Cómo verificar que el arreglo funcionó#

No deberías tener que fiarte de la palabra de nadie. Cada área de la auditoría tiene una comprobación que puedes hacer o pedir que te enseñen.

Velocidad: compara los datos de campo antes y después#

Guarda tu informe de Core Web Vitals antes de que empiece cualquier trabajo. Los datos de campo se acumulan en un periodo móvil de unas cuatro semanas, así que dales tiempo para reflejar los cambios. Luego compara LCP, INP y CLS con los umbrales, mirando primero el móvil.

Si una métrica mejoró en laboratorio pero no en datos de campo, el arreglo llegó a la prueba y no a tus visitantes. Pide al equipo que te explique qué sigue lento.

Seguridad: lo básico de OWASP para confirmar#

Usa el OWASP Top 10 como lista de comprobación en lenguaje llano. Para accesos: ¿puede un visitante llegar a una página de administración o a los datos de otro cliente, y han desaparecido las cuentas antiguas? Para la configuración: ¿están las cabeceras de seguridad, el modo debug desactivado y las cuentas por defecto eliminadas? Para los componentes: ¿el inventario no muestra versiones con vulnerabilidades conocidas?

Pide evidencias, como un análisis de cabeceras y la lista de componentes con sus versiones. Para ver el panorama completo, ciberseguridad de aplicaciones web: OWASP y qué deben priorizar los equipos B2B profundiza más.

Recuperación: restaura una copia una vez#

Una copia que nunca has restaurado es una esperanza. Pide al equipo que restaure la última en una copia de staging, comprueba que funcionan el inicio de sesión, los formularios y el checkout, y anota cuánto tardó. Ese tiempo es tu tiempo real de recuperación tras un incidente.

Cuando hayas hecho todas las comprobaciones, márcalas una por una.

• Los datos de campo de LCP, INP y CLS mejoraron frente a la referencia guardada
• Las cabeceras de seguridad como Strict-Transport-Security y Content-Security-Policy están presentes
• La lista de componentes no muestra versiones con vulnerabilidades conocidas
• Se revisaron las cuentas de administrador y se eliminó a los antiguos usuarios
• Se restauró una copia una vez en una copia de staging
• Las alertas de monitorización se probaron y llegan a la persona correcta

Cómo mantener tu sitio rápido y seguro#

Un sitio arreglado se deteriora despacio. Las nuevas versiones de plugins, los nuevos scripts de marketing y el personal nuevo lo cambian todo. El hábito que protege tu resultado es pequeño y regular: monitorizar, actualizar, revisar y leer un informe.

Qué debe vigilar la monitorización#

La monitorización debe avisarte de un problema antes que un cliente. Necesita vigilar cinco cosas:

• Disponibilidad y tiempo de respuesta de las páginas clave, como la home y el checkout.
• Fechas de caducidad de los certificados.
• Éxito de las copias de seguridad cada día.
• Tendencia de las Core Web Vitals en el tiempo.
• Actividad de inicio de sesión inusual y cambios inesperados en los archivos.

Una alerta solo sirve si la recibe una persona concreta y sabe qué hacer. Pruébalo una vez, como indica la lista de comprobación.

Qué cubre un plan de cuidado#

Un plan de cuidado convierte el ritmo de abajo en trabajo que alguien se encarga de hacer. Es la alternativa mensual a esperar la próxima emergencia. Para profundizar en el mantenimiento de WordPress, incluido quién arregla las actualizaciones que rompen el sitio, lee servicio de mantenimiento de WordPress: quién arregla las actualizaciones rotas.

1. Cada día

   Copias y control de disponibilidad

   Se hacen copias automáticas y se comprueban las páginas clave, con alertas a una persona concreta.

2. Cada semana

   Actualizaciones en una copia de staging

   Se actualizan plugins, temas y dependencias, se prueban y luego se publican.

3. Cada mes

   Informe escrito

   Recibes los hallazgos, el trabajo realizado y la tendencia de las Core Web Vitals.

4. Cada trimestre

   Revisión de accesos y plugins

   Se vuelven a comprobar cuentas, permisos y componentes sin usar.

Cómo leer un informe mensual#

Un buen informe responde cuatro preguntas en palabras sencillas. ¿Qué cambió en el sitio este mes? ¿Se mantuvo la velocidad frente a los umbrales? ¿Se bloqueó o se reparó algo? ¿Qué recomienda el equipo a continuación y cuánto costará?

Si un informe lista tareas y nunca menciona tu objetivo, pide que se vincule con consultas, ventas o reservas. Las cifras solo sirven cuando apuntan a una decisión.

Por dónde empezar esta semana#

Puedes dar el primer paso en una tarde, sin ningún proveedor. Abre el informe de Core Web Vitals en Google Search Console, o pasa tus páginas clave por PageSpeed Insights y lee la sección de datos de campo, y guarda una captura como referencia. Después anota a todas las personas con acceso de administrador al sitio, al hosting y al dominio, y marca a quien ya se fue.

Esas dos listas son casi todo lo que un auditor necesita para empezar. Llévalas, cuéntale a werun.dev tu objetivo (más consultas, menos ventas perdidas, ningún incidente) y construiremos el camino: una auditoría, un plan de arreglos ordenado y el mantenimiento que lo mantiene funcionando. Respondemos en menos de 2 horas en días laborables, y puedes comparar un proyecto puntual con un plan Care o un Retainer en la página de contratación. Cuando estés listo, cuéntanos sobre tu sitio.

Preguntas frecuentes#