8 min de lectura
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.
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.
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.
| 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.
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.
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.