https://example.com/artykul
y obtienes seis respuestas distintas:
- DNS afirma que el dominio apunta a dos direcciones IP,
- la capa TLS ve un certificado que no incluye
www, - tu navegador muestra una página correcta y personalizada,
- Googlebot indexa un título más antiguo,
- LinkedIn sigue mostrando la imagen anterior,
- un escáner de seguridad otorga una calificación baja por la falta de encabezados.
Ninguna de estas observaciones tiene por qué ser falsa.
Cada sistema observa un fragmento distinto de la pila, usa una caché diferente, envía un conjunto distinto de encabezados, puede conectarse desde otra ubicación y no siempre ejecuta JavaScript de la misma manera. La «verdad de una página web» no es un único documento. Es un conjunto de estados visibles para distintos clientes.
Conclusión más importante: un dominio puede funcionar correctamente en el navegador del propietario y, al mismo tiempo, tener un DNS erróneo para parte de los resolvers, un certificado incorrecto en un nodo CDN, contenido no indexable para Googlebot, una vista previa social antigua y una protección deficiente de las respuestas HTTP.
El artículo no asume que cada diferencia sea un error. La personalización, las variantes de idioma, la caché y la infraestructura distribuida son normales. El problema empieza cuando la diferencia es involuntaria, invisible en la monitorización o impide que un cliente concreto llegue a la versión correcta.
La documentación y el comportamiento de los sistemas descritos se verificaron el 23 de julio de 2026.
Seis perspectivas en una sola tabla
| Observador | Qué comprueba realmente | Qué no suele conocer | Qué puede cambiar el resultado |
|---|---|---|---|
| DNS | el nombre de host, los registros, la delegación, la caché, DNSSEC | el contenido HTML, la ruta de la URL, el título de la página | el resolver, el TTL, la región, IPv4/IPv6 |
| TLS | el endpoint, SNI, el certificado, SAN, la cadena, el protocolo | el contenido de la página y su SEO | la dirección IP, el nodo CDN, la configuración del virtual host |
| Navegador | DNS, TLS, HTTP, HTML, CSS, JavaScript, cookies, caché, DOM | la intención del autor y el estado de otros clientes | el usuario, el viewport, el locale, el storage, el service worker |
| Googlebot | la disponibilidad, robots, HTTP, HTML, los recursos, el renderizado, canonical, noindex | el contenido que requiere inicio de sesión o interacción | mobile-first, la caché de rastreo, la cola de renderizado, los bloqueos de recursos |
| Rastreador social | la URL, la redirección, los metadatos, la imagen de vista previa, la caché de la plataforma | la experiencia completa de la aplicación | la plataforma, la caché, Open Graph, la disponibilidad de la imagen |
| Escáner de seguridad | la superficie pública y las pruebas dentro de su alcance | toda la lógica de negocio, el código y los roles de usuario | el tipo de escáner, la autorización, la ruta, la configuración de la prueba |
«El mismo dominio» no siempre significa la misma prueba
Antes de comparar los resultados, define con precisión el recurso analizado:
http://example.com
https://example.com
https://www.example.com
https://example.com/
https://example.com/artykul
https://example.com/artykul?utm_source=test
Estas no son solicitudes técnicamente idénticas. Pueden:
- pasar por redirecciones distintas,
- usar hosts diferentes,
- llegar a otro virtual host,
- tener reglas de caché diferentes,
- apuntar a distintos canonical,
- devolver encabezados diferentes,
- generar tarjetas sociales independientes.
Una auditoría siempre debería registrar la URL completa, la hora, la ubicación de la prueba, el user-agent, el estado final y la cadena de redirecciones.
Verdad número 1: el DNS ve el nombre, no la página
El DNS traduce el nombre de host a los datos necesarios para localizar el servicio. En una consulta típica para:
https://example.com/artykul?id=42
al DNS le interesa el nombre:
example.com
No analiza la ruta /artykul, los parámetros ?id=42, el título HTML ni la etiqueta canonical. El DNS es un sistema jerárquico de nombres y registros de recursos.
¿Qué puede ver el diagnóstico del DNS?
Entre otras cosas:
example.com. IN A 192.0.2.10
example.com. IN AAAA 2001:db8::10
www.example.com. IN CNAME edge.example.net.
example.com. IN CAA 0 issue "letsencrypt.org"
También puede comprobar:
- los servidores
NS, - el registro
SOA, - el correo
MX, - los datos
TXT, - los registros
HTTPSySVCB, - las firmas DNSSEC.
¿Por qué dos personas pueden recibir respuestas diferentes?
La causa más simple es la caché. Un resolver puede conservar la respuesta hasta que expire el TTL. Las respuestas negativas, como NXDOMAIN, también pueden almacenarse en caché.
Las diferencias también pueden deberse a:
- resolvers distintos,
- versiones de caché diferentes,
- infraestructura geográfica o balanceo de carga del DNS,
- respuestas independientes para IPv4 e IPv6,
- migraciones entre operadores,
- servidores autoritativos inconsistentes,
- una cadena DNSSEC dañada.
DNSSEC autentica el origen y la integridad de los datos DNS, pero no cifra la consulta en sí. Un registro DS incorrecto puede hacer que un resolver validador devuelva SERVFAIL, mientras que un resolver sin validación seguirá mostrando la dirección.
¿Qué no confirma el DNS?
Una respuesta DNS correcta no demuestra que:
- el servidor funcione,
- el puerto 443 esté abierto,
- el certificado sea correcto,
- la aplicación devuelva el código
200, - la página sea indexable,
- los encabezados de seguridad estén implementados.
El DNS indica dónde debe intentar conectarse el cliente. No dice qué encontrará una vez conectado.
Verdad número 2: TLS ve la identidad del endpoint, no el contenido del artículo
Una vez localizada la dirección, el cliente establece una conexión con el servidor y negocia TLS. En un entorno que aloja varios dominios en una sola dirección, la extensión SNI permite al cliente indicar el nombre del servidor con el que quiere establecer la conexión.
La capa TLS puede revelar, entre otras cosas:
- las versiones de protocolo admitidas,
- el algoritmo negociado,
- el certificado del servidor,
- los nombres SAN,
- la autoridad de certificación,
- la fecha de validez,
- los certificados intermedios,
- el resultado de la negociación ALPN, por ejemplo HTTP/2.
TLS 1.3 se define en el RFC 8446 y protege el transporte de datos entre el cliente y el servidor.
El certificado corresponde al nombre, no al contenido
El cliente comprueba si el nombre de host coincide con la identidad registrada en el certificado, sobre todo en subjectAltName.
Un certificado para:
example.com
no tiene por qué incluir:
www.example.com
api.example.com
El comodín:
*.example.com
no incluye automáticamente el dominio raíz example.com ni el multinivel www.eu.example.com.
¿Por qué un usuario ve un certificado correcto y otro no?
Escenarios posibles:
AyAAAAapuntan a servidores distintos,- un nodo CDN no recibió el nuevo certificado,
- la configuración de SNI tiene un default virtual host incorrecto,
- el tráfico de una región concreta llega a otra infraestructura,
- el origin tiene un certificado distinto del edge público,
- parte de los servidores envía una cadena incompleta.
Sigue siendo «el mismo dominio» desde la perspectiva del usuario, pero no el mismo endpoint desde la perspectiva de la red.
¿Qué no sabe TLS?
Un TLS correcto no demuestra que:
- la página sea segura a nivel de aplicación,
- el JavaScript no tenga XSS,
- el usuario tenga los permisos adecuados,
- el canonical sea correcto,
- Google indexe el contenido,
- la tarjeta de Open Graph tenga una buena imagen.
El candado verde indica una conexión protegida con un nombre aceptado por el cliente. No es un certificado de calidad de toda la aplicación.
Verdad número 3: el navegador ve el resultado del funcionamiento de todo el entorno
El navegador realiza mucho más trabajo que una simple descarga del HTML. Una navegación típica incluye el DNS, la conexión de transporte, TLS, la solicitud HTTP, el análisis del HTML, la descarga de CSS y JavaScript, la construcción del DOM y del CSSOM, el layout y el renderizado de píxeles.
Lo que el usuario ve en pantalla puede ser distinto del código fuente de la respuesta.
El HTML fuente, el DOM y la pantalla son tres cosas distintas
El HTML del servidor
<div id="app"></div>
<script src="/app.js"></script>
El DOM tras ejecutar JavaScript
<div id="app">
<h1>Raport dla zalogowanego użytkownika</h1>
</div>
La imagen en pantalla
En el aspecto final influyen además el CSS, las fuentes, el tamaño del viewport, la disponibilidad de las imágenes, la configuración del sistema y las interacciones del usuario.
¿Qué personaliza la «verdad del navegador»?
- las cookies y la sesión,
localStorageysessionStorage,- el idioma del navegador,
- la zona horaria,
- el ancho de la pantalla,
prefers-color-scheme,prefers-reduced-motion,- los permisos,
- el experimento A/B,
- las respuestas de la API,
- el estado de inicio de sesión.
El navegador también tiene una caché HTTP privada. Una respuesta almacenada como fresca puede reutilizarse sin volver a descargarla, según las directivas de caché.
Un service worker puede interceptar las solicitudes y devolver datos desde su propia caché o desde una estrategia offline personalizada. Esto explica las situaciones en las que una simple recarga sigue mostrando la versión antigua, mientras que el modo privado presenta la nueva.
¿Por qué «a mí me funciona» es una prueba débil?
El propietario de la página puede tener:
- una sesión de administrador activa,
- datos en caché,
- un service worker antiguo,
- acceso a una API no disponible públicamente,
- otro idioma y región,
- extensiones que modifican la página,
- un banner u onboarding ya descartado.
Una prueba en el navegador debería incluir un perfil limpio, el modo privado, un dispositivo móvil, IPv4, IPv6 y un usuario sin iniciar sesión.
Verdad número 4: Googlebot ve una página destinada al rastreo, el renderizado y la indexación
Google describe el tratamiento de las páginas con JavaScript como tres fases principales:
- crawling,
- rendering,
- indexing.
Googlebot descarga la URL, analiza la respuesta y puede enviar la página al Web Rendering Service. Google usa para el renderizado una versión actual de Chrome, pero el resultado no tiene por qué producirse en el mismo momento que la primera descarga.
Googlebot no es un usuario normal
Google tiene Googlebot Smartphone y Desktop y, para la mayoría de las páginas, indexa sobre todo la versión móvil. Por tanto, la mayoría de las solicitudes proviene del rastreador móvil.
Googlebot:
- no inicia sesión en tu cuenta,
- no tiene tus cookies,
- no ve datos privados,
- no se comporta como un usuario que ejecuta todos los escenarios,
- puede descargar los recursos por separado,
- está sujeto a robots.txt y a los controles de indexación.
Google indica claramente que no cargará el contenido principal que requiere interacción, como hacer clic, introducir datos o desplazar un elemento.
Robots.txt no es lo mismo que noindex
robots.txt controla qué URL puede descargar el rastreador. Google subraya que no es un mecanismo que garantice la eliminación de una URL de los resultados.
Para que noindex funcione, el rastreador debe poder descargar la página y ver la etiqueta o el encabezado. Si la URL está bloqueada al mismo tiempo en robots.txt, Google puede no ver el noindex.
<meta name="robots" content="noindex">
o:
X-Robots-Tag: noindex
El canonical es una indicación, no una orden incondicional
<link rel="canonical" href="https://example.com/artykul">
Google puede elegir una versión canonical distinta de la indicada por el propietario, porque la canonicalización tiene en cuenta muchas señales. Google describe la indicación canonical como una sugerencia, no como una regla.
¿Qué puede ver el usuario pero no Googlebot?
- el contenido solo tras hacer clic en «Mostrar más»,
- los datos disponibles solo tras iniciar sesión,
- un elemento que depende de una API no disponible,
- el contenido cargado por un script bloqueado,
- una versión de escritorio más rica que la móvil,
- un componente que solo funciona con datos guardados en el navegador.
¿Qué puede ver Googlebot pero no un usuario típico?
Por ejemplo, el servidor puede devolver una variante distinta para su user-agent. La simple adaptación técnica no es automáticamente una infracción, pero mostrar de forma deliberada al buscador un contenido esencialmente distinto del que ven los usuarios puede considerarse cloaking.
La práctica más segura es ofrecer el mismo contenido relevante en la respuesta inicial o en un renderizado que no requiera interacción del usuario.
Verdad número 5: el rastreador social construye una tarjeta, no la experiencia completa de la página
Cuando una URL se pega en Facebook, LinkedIn, Slack u otra plataforma, el sistema puede descargar la página y construir una vista previa. No conviene dar por hecho que cada plataforma ejecuta la aplicación JavaScript exactamente igual que el navegador completo del usuario.
La forma más portable de describir una página son los metadatos incluidos en el <head> del HTML inicial.
Open Graph básico
La especificación de Open Graph define cuatro propiedades obligatorias:
<meta property="og:title" content="Tytuł artykułu">
<meta property="og:type" content="article">
<meta property="og:image" content="https://example.com/og/article.jpg">
<meta property="og:url" content="https://example.com/artykul">
En la práctica conviene añadir:
<meta property="og:description" content="Opis artykułu">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Opis grafiki">
Meta/Facebook
Meta recomienda usar etiquetas de Open Graph para que el rastreador pueda obtener el título, la descripción y la imagen de vista previa. La documentación de Meta también describe la obtención y el almacenamiento en caché de los metadatos al compartir una URL.
Esto significa que cambiar la imagen en el servidor no tiene por qué cambiar de inmediato una tarjeta existente. La plataforma puede seguir conservando una instantánea más antigua.
LinkedIn indica que las vistas previas utilizan, entre otros, Open Graph u oEmbed. La imagen antigua puede proceder de la caché, y Post Inspector permite actualizar los datos para nuevas publicaciones compartidas.
Las publicaciones existentes pueden conservar la vista previa anterior incluso después de actualizar la URL.
Slack
Slack documenta el unfurling clásico como un proceso en el que, tras detectar un enlace, el sistema rastrea la página y crea una vista previa. Las aplicaciones de Slack también pueden proporcionar sus propios unfurls programables.
Es una distinción importante: la tarjeta en Slack puede ser el resultado estándar del rastreo o un objeto personalizado devuelto por una integración.
¿Por qué las plataformas muestran imágenes diferentes?
- una plataforma tiene una caché antigua,
- otra no puede descargar la imagen,
- la URL de la imagen redirige,
- la imagen tiene un MIME o un código de estado no válido,
- varias
og:imagetienen un orden distinto, - la página tiene etiquetas separadas para distintas versiones de idioma,
- el bot recibe una variante distinta a través del CDN o del firewall,
- los metadatos se añaden solo mediante JavaScript.
Lo más seguro es colocar las etiquetas sociales básicas directamente en el HTML del servidor e indicar direcciones HTTPS absolutas.
Verdad número 6: el escáner de seguridad solo ve el alcance que es capaz de analizar
«Escáner de seguridad» puede referirse a herramientas muy diferentes:
- un analizador de encabezados HTTP,
- un escáner de configuración TLS,
- un DAST que ejecuta solicitudes y pruebas de vulnerabilidades,
- un rastreador de la aplicación,
- un SAST que analiza el código,
- un escáner de dependencias,
- una herramienta de pruebas de infraestructura.
En este artículo hablamos sobre todo de un escáner externo que analiza una página de acceso público.
¿Qué ve un escáner de encabezados?
MDN HTTP Observatory evalúa principalmente los encabezados HTTP y ciertas configuraciones de seguridad.
Puede comprobar, entre otras cosas:
- CSP,
- HSTS,
- la protección contra el framing,
X-Content-Type-Options,- las cookies,
- la redirección a HTTPS,
- ciertas políticas cross-origin.
Esto no significa que haya leído el código del backend, los roles de usuario, la configuración de la base de datos ni todos los endpoints de la API.
La calificación por letras no es un veredicto sobre toda la seguridad
La documentación de Observatory señala que la puntuación pretende indicar mecanismos de seguridad no utilizados, y la necesidad de un encabezado concreto puede depender del tipo de sitio web.
Una página puede obtener una puntuación alta de encabezados y aun así tener:
- IDOR,
- una autorización incorrecta,
- SQL Injection,
- un panel de administración vulnerable,
- claves expuestas,
- una lógica de negocio que permite abusos.
También es posible la situación inversa: un simple endpoint JSON obtendrá una calificación más baja por la falta de encabezados típicos de un documento HTML, aunque algunos de ellos no tengan para él la misma importancia.
DAST tiene otro alcance, pero también limitaciones
OWASP describe los web application vulnerability scanners como herramientas que prueban las aplicaciones desde el exterior en busca de vulnerabilidades y configuraciones incorrectas.
ZAP advierte de que el escaneo automático tiene limitaciones. Sin una autenticación configurada, no descubrirá las páginas tras el inicio de sesión, y un spider automático no ejecutará todos los procesos de usuario realistas.
El resultado depende de:
- la cuenta y el rol utilizados en la prueba,
- las URL disponibles,
- los formularios y los datos de prueba,
- el alcance de los dominios,
- el user-agent,
- los límites del WAF,
- el tiempo de escaneo,
- si el escáner ejecuta JavaScript.
El escáner dice: «dentro de este alcance encontré o no encontré ciertas señales». No dice: «he demostrado la ausencia de todas las vulnerabilidades».
Una URL, seis informes correctos
El siguiente ejemplo es hipotético, pero técnicamente realista.
Dirección analizada:
https://example.com/raport
DNS
A: 192.0.2.10
AAAA: 2001:db8::20
TTL: 300
Conclusión: el dominio tiene dos endpoints posibles.
TLS por IPv4
SAN: example.com, www.example.com
TLS: 1.3
Chain: poprawny
TLS por IPv6
SAN: old.example.net
TLS: 1.2
Chain: poprawny, ale zła nazwa
Conclusión: parte de los clientes no abrirá la página.
El navegador del propietario
- usa IPv4,
- tiene una sesión activa,
- el service worker devuelve la versión de la caché,
- muestra el informe actual.
Conclusión del usuario: «todo funciona».
Googlebot Smartphone
- llega por IPv6,
- no puede completar TLS,
- no descarga la página.
Conclusión de SEO: el nuevo contenido no se rastrea.
- tiene una vista previa guardada una semana antes,
- muestra la
og:imageanterior.
Conclusión de marketing: la tarjeta está desactualizada.
Escáner de encabezados
- prueba IPv4,
- descarga el documento sin iniciar sesión,
- detecta la falta de CSP y HSTS.
Conclusión de seguridad: el transporte funciona, pero el hardening de la respuesta es incompleto.
Todos los informes describen un fragmento distinto del sistema.
Matriz de síntomas
| Síntoma | Perspectiva más probable | Primera prueba |
|---|---|---|
| La página solo funciona para parte de los usuarios | DNS, IPv6 o TLS | dig A/AAAA, prueba de ambas direcciones |
| Certificado de otro dominio | TLS/SNI | openssl s_client -servername |
| Tras el despliegue se sigue viendo la página antigua | caché del navegador o service worker | perfil limpio, DevTools Application |
| Google muestra un título antiguo | caché de rastreo/índice u otro canonical | URL Inspection, revisión del rendered HTML |
| La página no está en el índice | robots, noindex, errores de rastreo | robots.txt, Search Console |
| Facebook o LinkedIn muestra una imagen antigua | caché del rastreador social | debugger o Post Inspector |
| El escáner indica la falta de HSTS, pero el navegador usa HTTPS | encabezados de respuesta | curl -I para la URL final |
| El resultado del escáner es bueno, pero una función tiene un error de acceso | lógica de la aplicación fuera del alcance del escáner | prueba de autorización y roles |
| El contenido móvil es más pobre en Google | mobile-first y contenido distinto | comparación del render móvil |
noindex no funciona |
URL bloqueada en robots.txt | permitir el rastreo y volver a probar |
Metodología de una auditoría completa
1. Registra la cadena completa de URL
curl -IL https://example.com/artykul
Presta atención a:
- los estados,
- el cambio de host,
- la transición HTTP→HTTPS,
- la URL final,
- el número de redirecciones.
2. Comprueba el DNS desde varios resolvers
dig example.com A
dig example.com AAAA
dig example.com NS
dig example.com CAA
dig example.com A +dnssec
Compara las respuestas del resolver del operador, un resolver público y un servidor autoritativo.
3. Comprueba cada endpoint TLS
openssl s_client \
-connect 192.0.2.10:443 \
-servername example.com \
-showcerts
Repite para IPv6 y otras direcciones devueltas por el DNS.
4. Comprueba la respuesta HTTP sin estado de usuario
curl -sS -D headers.txt https://example.com/artykul -o page.html
Verifica:
- el código de estado,
Content-Type,- la caché,
- CSP,
- HSTS,
X-Robots-Tag,- el contenido de
<head>.
5. Compara el HTML fuente y el DOM
En el navegador comprueba:
- View Source,
- el panel Elements,
- Network,
- Application,
- el service worker activo,
- cache storage,
- las cookies.
6. Comprueba Googlebot
Usa la herramienta URL Inspection en Google Search Console y compara:
- el HTML descargado,
- el HTML renderizado,
- la captura de pantalla,
- los recursos que no se pudieron cargar,
- el canonical indicado y el elegido por Google,
- la posibilidad de indexación.
No identifiques a Googlebot únicamente por el user-agent. Google recomienda verificarlo mediante reverse DNS o los rangos de IP oficiales.
7. Comprueba la tarjeta social
Analiza:
<title>
<meta name="description">
<meta property="og:title">
<meta property="og:description">
<meta property="og:image">
<meta property="og:url">
A continuación, usa las herramientas de actualización de la plataforma concreta.
8. Ejecuta varias clases de pruebas de seguridad
- el análisis de encabezados,
- la prueba de TLS,
- DAST en un entorno destinado a ello,
- pruebas de autenticación y autorización,
- el análisis de dependencias,
- la revisión del código y la configuración.
Una sola evaluación no sustituye a las demás.
Un <head> modelo accesible para distintos clientes
<!doctype html>
<html lang="pl">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Jedna domena, sześć różnych prawd</title>
<meta
name="description"
content="Jak DNS, TLS, przeglądarka, Googlebot, social crawler i skaner bezpieczeństwa widzą tę samą domenę."
>
<link
rel="canonical"
href="https://example.com/jedna-domena-szesc-prawd"
>
<meta name="robots" content="index,follow">
<meta
property="og:title"
content="Jedna domena, sześć różnych prawd"
>
<meta property="og:type" content="article">
<meta
property="og:url"
content="https://example.com/jedna-domena-szesc-prawd"
>
<meta
property="og:image"
content="https://example.com/images/six-truths-1200x630.jpg"
>
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta
property="og:image:alt"
content="Schemat sześciu warstw obserwujących jedną domenę"
>
</head>
Los metadatos más importantes están en la respuesta HTML, y no solo después de ejecutar la aplicación.
Lista de comprobación práctica de las «seis verdades»
DNS
-
AyAAAAapuntan a endpoints activos. - Todos los servidores autoritativos devuelven datos coherentes.
- El TTL es comprensible y está monitorizado.
- DNSSEC supera la validación.
-
wwwy el apex tienen el comportamiento previsto. - La prueba se realizó desde varios resolvers y ubicaciones.
TLS
- Cada dirección IP devuelve el certificado correcto.
- SAN incluye cada hostname utilizado.
- La cadena está completa.
- IPv4 e IPv6 tienen la misma calidad de configuración.
- SNI selecciona el virtual host correcto.
- El CDN y el origin tienen un TLS correcto.
Navegador
- La página funciona en un perfil limpio.
- Se comprobó la versión sin iniciar sesión.
- El HTML fuente contiene el contenido clave y los metadatos.
- El DOM tras el renderizado se ajusta a lo esperado.
- El service worker y la caché no enmascaran el despliegue.
- La versión móvil contiene el contenido completo.
- Los errores de la API se gestionan.
Googlebot
- robots.txt permite descargar la página y los recursos.
-
noindexse ajusta a la intención. - El canonical es coherente con las redirecciones y el sitemap.
- El contenido principal no requiere hacer clic.
- El render móvil contiene el mismo contenido relevante.
- URL Inspection muestra el HTML y la captura de pantalla correctos.
- Los recursos CSS y JS están disponibles.
Rastreador social
- El Open Graph básico se encuentra en el HTML inicial.
-
og:urlapunta a la URL permanente correcta. -
og:imagees una dirección HTTPS absoluta. - La imagen devuelve
200y un MIME correcto. - Las dimensiones de la imagen están declaradas.
- Cada versión de idioma tiene los metadatos correctos.
- La caché de la plataforma se actualizó tras el cambio.
Seguridad
- Se probaron los encabezados de la respuesta final.
- La prueba abarca más que la homepage.
- Se comprobaron los endpoints tras iniciar sesión.
- Los roles de usuario se probaron por separado.
- Los resultados automáticos fueron verificados por una persona.
- El DAST se complementó con SAST y análisis de dependencias.
- La calificación baja o alta se interpretó en su contexto.
Herramientas de POLPROG útiles en una auditoría así
- Inspector de DNS y SSL muestra los registros del dominio y los datos del certificado.
- Open Graph Preview comprueba los metadatos y la tarjeta para compartir.
- Inspector de encabezados de seguridad analiza el hardening de las respuestas HTTP.
- Estado del sitio web combina señales de SEO, rendimiento, accesibilidad y seguridad.
- FlowTrace visualiza el recorrido desde un evento en el navegador a través del DNS, TLS, el CDN, el backend y el renderizado.
Mitos más comunes
«Si la página me funciona a mí, funciona en todas partes»
No. Tu resolver, tu protocolo IP, tu caché, tus cookies y tu nodo CDN pueden ser diferentes.
«Google ve exactamente lo mismo que Chrome»
Google renderiza las páginas con Chrome, pero Googlebot tiene otro estado, un user-agent mobile-first, fases separadas de rastreo y renderizado y no ejecuta el contenido que requiere interacción.
«Robots.txt elimina la página de Google»
No. Robots.txt limita el rastreo. Para controlar la indexación se usa noindex, que debe ser visible para el rastreador.
«El canonical obliga a Google a usar la URL elegida»
No. Es una señal importante, pero Google puede elegir otro canonical.
«Cambié la og:image, así que la tarjeta ya es nueva»
No siempre. La plataforma puede usar la versión guardada y requerir que se vuelva a descargar la URL.
«Una A+ en el escáner significa que la aplicación es segura»
No. Significa una puntuación alta en un conjunto concreto de pruebas. No demuestra una autorización correcta, una lógica de negocio adecuada ni la seguridad del código.
Veredicto
Un dominio no tiene una única «cara» técnica.
- El DNS ve el nombre y los registros.
- TLS ve el endpoint y la identidad del certificado.
- El navegador ve la experiencia renderizada de un usuario concreto.
- Googlebot ve un recurso disponible para el rastreo, el renderizado y la indexación.
- el rastreador social ve los metadatos necesarios para construir la tarjeta.
- el escáner de seguridad ve únicamente la superficie cubierta por sus pruebas.
Por tanto, una auditoría madura no solo pregunta: «¿Funciona la página?»
Pregunta:
Dla kogo?
Z jakiej lokalizacji?
Po IPv4 czy IPv6?
Z jakim stanem cache?
Z jakim user-agentem?
Przed czy po wykonaniu JavaScriptu?
Z logowaniem czy bez?
W jakim zakresie testu?
Solo las respuestas a estas preguntas conforman una imagen coherente del sistema.
