Auditar la propia web: método, evidencia y límites

Respuesta breve

Auditar la web propia solo demuestra método si el resultado conserva los defectos, no únicamente las correcciones. Eso exige tres condiciones: un candidato inmutable identificado por commit y hashes, revisores que inspeccionen desde perspectivas distintas sin editar en la primera pasada, y un informe que separe lo corregido de lo aceptado y lo bloqueado con su motivo. Sin candidato fijo, cada hallazgo se refiere a un estado distinto del sitio y la auditoría deja de ser una foto para convertirse en una mezcla. Sin la disciplina de publicar lo que salió mal, el ejercicio se convierte en una demostración comercial que no acredita nada.

Puntos clave

• El candidato se fija antes de auditar: commit, árbol, ZIP, hashes, versiones y datos de fixture.
• Si cambian los bytes después de auditar, las pruebas afectadas se repiten; no se mezclan estados.
• Tres perspectivas independientes, y en la primera pasada se inspecciona sin corregir.
• Cada hallazgo lleva severidad, ubicación, pasos de reproducción, impacto y corrección esperada.
• Una puntuación automática no sustituye la revisión manual ni los datos de campo.
• El informe distingue corregido, aceptado y bloqueado; Critical y High impiden la publicación.
• Los artefactos no contienen secretos, rutas personales, correos, teléfonos ni volcados de datos.

Auditar la propia web sin engañarse

1. Fijar el candidatoCommit, árbol, ZIP, hashes, versiones y datos de fixture.
2. Tres perspectivasIndependientes; en la primera pasada se inspecciona sin corregir.
3. Evidencia por hallazgoSeveridad, ubicación, reproducción, impacto y corrección esperada.
4. Publicar los fallosCorregido, aceptado o bloqueado; Critical y High impiden publicar.
5. Sin datos privadosLos artefactos no llevan secretos, rutas, correos ni volcados.

Fijar el candidato

Registra commit, árbol, ZIP, hashes, versiones y datos de fixture. Si cambian bytes después de auditar, repite las pruebas afectadas. Separa runtime local, staging y producción.

La ficha del candidato es un archivo corto que acompaña a todo el informe: identificador del commit, hash del paquete evaluado, versiones de PHP, del gestor de contenidos, del tema y de cada extensión activa, y origen del conjunto de datos de prueba. Con ella, cualquier persona puede reconstruir el estado exacto sobre el que se emitieron los hallazgos. Sin ella, un hallazgo es una anécdota fechada.

La separación de entornos evita la confusión más costosa. Un fallo reproducido en local puede no existir en producción por diferencias de configuración del servidor, y uno observado en producción puede depender de una capa —caché, proxy, protección— que en local no está. Cada hallazgo indica en qué entorno se reprodujo, y los que solo aparecen en uno se marcan como tales en lugar de generalizarse.

Tres perspectivas

• estrategia, contenido y conversión;
• WordPress, seguridad y operaciones;
• UX, accesibilidad, rendimiento y visual.

Los revisores inspeccionan sin editar en la primera pasada. Cada hallazgo tiene severidad, ubicación, reproducción, impacto y corrección esperada. Después el equipo corrige y las tres revisiones se repiten.

La razón de separar perspectivas es que cada una encuentra defectos que las otras no ven, y mezclarlas produce un listado dominado por lo que resulta más visible. La revisión de contenido detecta promesas sin respaldo y páginas sin misión; la de operaciones detecta permisos, actualizaciones pendientes y procedimientos de recuperación sin probar; la de experiencia detecta el foco perdido, el contraste insuficiente y el trabajo innecesario del navegador. Un mismo revisor haciendo las tres tiende a profundizar en la que domina.

La prohibición de editar durante la primera pasada tiene una función concreta: separar el diagnóstico de la corrección. Cuando quien encuentra el fallo lo arregla al instante, el registro del defecto se pierde y el informe final solo muestra un sitio correcto. Anotar primero y corregir después es lo que permite publicar la lista de lo que estaba mal.

Evidencia mínima

Comandos y códigos de salida, informes de crawler, axe, Lighthouse, screenshots, pruebas de teclado, activación limpia, upgrade, backup y rollback. Una puntuación automática no sustituye revisión manual ni datos de campo.

La distinción entre comprobación automática y manual organiza el trabajo. Lo automático cubre bien lo que se puede expresar como regla: enlaces rotos, respuestas HTTP, ausencia de alternativas textuales, contraste calculado, peso de recursos. Lo manual cubre lo que exige criterio: si la alternativa textual describe la imagen, si el orden de foco tiene sentido, si el contenido responde a la tarea, si el procedimiento de restauración funciona de verdad cuando se ejecuta.

Las pruebas de operación son las que más se declaran y menos se ejecutan. Una copia de seguridad que nunca se ha restaurado no es una copia de seguridad, es una intención. La evidencia que corresponde es el registro de una restauración real sobre un entorno limpio, con su fecha, su duración y el resultado de comprobar que el sitio funciona después. Lo mismo se aplica a la actualización: instalar una versión nueva sobre el candidato y verificar que no rompe nada es una prueba, leer el registro de cambios no lo es.

Sobre rendimiento, la regla que evita casi todas las malas lecturas es no confundir laboratorio con campo. Una herramienta local produce cifras reproducibles y comparables entre variantes; los umbrales de Core Web Vitals —LCP por debajo de 2,5 s, INP por debajo de 200 ms y CLS por debajo de 0,1— se evalúan en el percentil 75 de las visitas reales. Citarlos junto a una medición de laboratorio como si acreditaran cumplimiento es un error de categoría. La metodología está en Core Web Vitals en WordPress.

Una copia de seguridad que nunca se ha restaurado no es una copia de seguridad, es una intención.

Publicar fallos

El informe distingue corregidos, aceptados y bloqueados. Un Medium aceptado necesita motivo y plan; Critical o High impiden release. No se eliminan resultados porque perjudiquen la narrativa.

«Aceptado» es una categoría legítima y necesaria, siempre que venga acompañada de la razón y de una fecha de revisión. Aceptar un defecto de severidad media porque su corrección depende de un tercero, o porque el coste supera al beneficio en este ciclo, es una decisión defendible. Aceptarlo sin escribir por qué es esconderlo con otro nombre.

Publicar lo que salió mal es más fácil de defender que de hacer. Un ejemplo de esta misma web: la migración de WordPress a un sitio estático, contada con lo que no mejoró, donde la medición que justificaba el trabajo resultó estar atribuida a la causa equivocada.

Los cuatro estados de un hallazgo en el informe y lo que cada uno exige.

Estado	Qué significa	Qué exige el informe
Corregido	resuelto y verificado en una pasada posterior	evidencia antes y después sobre el mismo candidato
Aceptado	se conoce y no se corrige en este ciclo	motivo, responsable y fecha de revisión
Bloqueado	depende de un tercero o de una decisión pendiente	qué falta y quién puede desbloquearlo
No reproducible	no se ha podido observar de nuevo	entorno, intentos y condiciones probadas

El umbral de bloqueo por severidad tiene que fijarse antes de auditar, no cuando aparece el primer hallazgo incómodo. Decidir en ese momento si un fallo alto impide publicar convierte el criterio en una negociación. Fijado de antemano, es una regla.

Privacidad

Los artefactos no incluyen secretos, paths personales, emails, teléfonos, mensajes o backups. Las capturas usan datos sintéticos. Los logs se sanitizan y los dumps permanecen fuera del repositorio.

La revisión de privacidad se hace sobre los artefactos antes de publicarlos, no sobre la intención de quien los generó. Una captura de un panel de administración puede mostrar el nombre de usuario real; una traza de red puede contener una cabecera de autenticación; un informe de rastreo puede incluir URLs con identificadores de sesión. La comprobación es leer cada archivo que va a salir y buscar activamente esos patrones, con la misma disciplina con que se revisa el código antes de un despliegue.

El conjunto de datos de prueba resuelve el problema en origen. Si el fixture contiene nombres inventados, direcciones ficticias y pedidos sintéticos, las capturas son publicables por construcción y no hace falta editar imágenes a posteriori, que es donde se cuelan los descuidos.

Regla de reproducibilidad

Cada hallazgo publicable debe identificar el artefacto evaluado, la versión del código, el entorno, el comando o procedimiento y el criterio de aprobación. Las capturas aisladas no bastan cuando el resultado puede expresarse como archivo, test o lectura estructurada. Si una prueba depende de red, caché o un servicio externo, el informe separa esa dependencia de las comprobaciones locales.

La repetición debe partir del mismo candidato. Si se corrige código entre pasadas, se genera una nueva evidencia y se conserva la anterior como antecedente. Esta disciplina evita presentar una mezcla de estados como si fuese una única auditoría.

El criterio de aprobación es la parte que más se omite y la que convierte un hallazgo en accionable. «El formulario tiene problemas de accesibilidad» no se puede cerrar; «cada campo tiene una etiqueta asociada por for, el error se anuncia en el mismo elemento y el orden de foco recorre el formulario sin saltos» sí. Quien corrige sabe qué hacer y quien revisa sabe cuándo está hecho.

Ganancia editorial

La pieza puede enlazar la metodología con evidencia real y explicar decisiones que un lector puede reproducir. El proceso de auditoría técnica sirve como plantilla, pero no reemplaza los resultados.

El valor de auditar la propia web no está en el resultado sino en el procedimiento publicado. Un informe que enseña qué se midió, con qué criterio y qué salió mal es verificable por quien lo lee; una lista de aciertos no lo es. Esa asimetría es la razón por la que el ejercicio merece la pena aunque el resultado no sea impecable, y la razón por la que un resultado impecable debería levantar sospechas.

En cuatro láminas

curl -s https://seonidas.com/ | jq '.["@graph"][]["@type"]'. WebSite publisher → #negocio / ProfessionalService areaServed: ES · sin dirección / Person Jesús Iturbide · worksFor → #negocio. Leído el 28 de septiembre de 2026.

3 perspectivas independientes. Contenido, operaciones y experiencia. En la primera pasada se inspecciona sin corregir.

real: id: H-05 / severidad: Alto / ubicación: metadatos de todo el sitio / reproducción: frase declarada vs. su description / impacto: 29 de 31 descripciones sin su frase / corrección: reescribirlas empezando por la intención / estado: cerrado · 32 de 32 verificadas

Errores frecuentes

• Auditar sobre un candidato en movimiento. Si el código cambia durante la revisión, los hallazgos se refieren a estados distintos.
• Corregir mientras se inspecciona. El defecto desaparece del registro y el informe solo muestra el resultado final.
• Confiar en la puntuación de una herramienta. Agrega métricas con pesos propios y no ve lo que exige criterio.
• Presentar mediciones de laboratorio como datos de campo. Los umbrales de Core Web Vitals se evalúan en el percentil 75 de visitas reales.
• Declarar una copia de seguridad sin haberla restaurado. Sin restauración probada, no hay evidencia.
• Aceptar hallazgos sin motivo escrito. Es esconderlos con otra etiqueta.
• Publicar artefactos sin revisar. Capturas, trazas y logs filtran datos con facilidad.
• Fijar el umbral de bloqueo cuando aparece el fallo. Convierte el criterio en una negociación.

Preguntas habituales

¿Se puede auditar la propia web sin engañarse?

No del todo, y ese es el punto de partida. Quien construyó una decisión conoce sus razones y tiende a puntuarla mejor de lo que merece. Lo que reduce el sesgo no es la buena intención, sino el método: criterios escritos antes de mirar, evidencia por hallazgo y un umbral que se cumple o no se cumple, sin margen para el «casi».

¿Por qué publicar también lo que salió mal?

Porque un informe donde todo está bien no informa de nada: no se distingue de uno hecho sin mirar. Los fallos publicados son lo que permite a un lector juzgar el método, repetirlo en su web y saber qué esperar del trabajo. Además obligan a arreglarlos, que es la parte útil.

¿Qué evidencia mínima necesita un hallazgo?

La URL afectada, el dato que lo demuestra, con qué se midió y cuándo. Sin esos cuatro elementos el hallazgo es una opinión: no se puede comprobar, no se puede repetir y no se puede saber si sigue vigente dentro de tres meses. Un hallazgo sin evidencia se retira del informe, no se suaviza.

¿Cada cuánto conviene repetir una auditoría así?

Depende de cuánto cambie el sitio, no del calendario. Una web que publica cada semana acumula deriva más rápido que una estática. Lo sostenible es dejar comprobaciones automáticas que avisen cuando algo empeora y reservar la revisión completa para los cambios grandes: rediseño, migración o un desplome que no se explica solo.

Próximo paso

Antes de revisar nada, escribe la ficha del candidato y el umbral de severidad que impide publicar. Después reparte las tres perspectivas y ejecuta la primera pasada sin corregir ni una línea, anotando cada hallazgo con su criterio de aprobación. Al terminar, corrige, vuelve a pasar las tres revisiones sobre el nuevo candidato y publica el informe con los tres estados —corregido, aceptado y bloqueado— y sus motivos. Si es la primera vez, empieza por una sola plantilla en lugar del sitio entero: una auditoría pequeña y completa vale más que una amplia sin evidencia.

Fuentes

• Google Search Central, cómo funciona la Búsqueda — descubrimiento, rastreo e indexación.
• Google Search Central, introducción a robots.txt — qué controla y qué no.
• web.dev, Core Web Vitals — definición de las métricas.
• Google Search Central, contenido útil — guía.

Servicio relacionado

Si esto es lo que te está pasando, auditoría seo es el trabajo que lo resuelve. Diagnóstico primero, prioridades después.

Ver auditoría seo