Inspeccionar una página web: qué revisar y cómo hacerlo

Por el equipo creativo de Virtalio, una agencia creativa con más de 15 años construyendo sitios y piezas de marca para empresas de Latinoamérica. Última revisión: noviembre de 2026.

Inspeccionar una página web es revisar tres capas en orden: lo que entrega el servidor (código fuente, cabeceras, canónica), lo que ejecuta el navegador (peso, errores, orden de carga) y lo que el buscador tiene registrado (robots.txt, sitemap, indexación). Cada capa explica un problema distinto. Un formulario que no envía no aparece en el código fuente, y una página que no sale en Google rara vez se arregla cambiando el diseño. Abajo está el orden en que se mira, qué se busca en cada paso y la lista que usamos antes de publicar.

Las tres capas, y el síntoma que explica cada una

La revisión falla cuando empieza por el lugar equivocado. Alguien nota que una página tarda, abre el editor, cambia una imagen y sigue igual: el problema estaba en un script de terceros que bloquea el renderizado. Alguien ve que una página no aparece en Google y reescribe los textos: el problema era una etiqueta noindex heredada de una migración.

• Capa 1, servidor. El HTML que llega antes de que corra una línea de JavaScript, más las cabeceras HTTP. Explica indexación, canibalización, redirecciones y metadatos.
• Capa 2, navegador. El DOM ya renderizado, la pestaña de red y la consola. Explica lentitud, saltos de maquetación, recursos que faltan y errores que rompen una interacción.
• Capa 3, buscador. Lo que Google guardó de esa URL: si está indexada, qué canónica eligió y cuándo la rastreó. Explica por qué una página técnicamente correcta sigue sin tráfico.

En un sitio propio las tres capas se revisan en menos de una hora. En el sitio de un cliente o de un competidor solo las dos primeras están disponibles, y eso cambia lo que se puede concluir.

Capa 1: el código que llega antes de que nada se ejecute

Abre la página y usa «Ver código fuente»: Ctrl+U en Windows, Cmd+Option+U en Mac. Lo que aparece es la respuesta del servidor, no la pantalla que ves. La diferencia importa porque los bloques que arma JavaScript —un carrusel, un precio que cambia por región, un comentario cargado al hacer clic— no están ahí.

En el <head> se revisan cinco cosas, en este orden:

• El título. Uno por página, distinto en cada URL, escrito para la intención de esa página y no para la marca. Si dos páginas comparten título, compiten entre ellas.
• La descripción. No posiciona, pero decide el clic. Debe describir lo que hay en la página y no repetir el título con otras palabras. Google la reescribe cuando la considera floja o cuando no existe.
• La canónica. <link rel="canonical"> declara cuál es la URL que debe indexarse cuando el mismo contenido vive en varias direcciones: con y sin www, con parámetros de campaña, con barra final. Una canónica que apunta a otra página le dice a Google que esta no importa.
• La directiva de robots. <meta name="robots" content="noindex"> saca la página del índice. Es la causa más común de «no aparece en Google» y casi siempre es un resto de staging que nadie quitó.
• Las etiquetas sociales y los datos estructurados. og:title, og:description y og:image definen cómo se ve el enlace al compartirlo; el protocolo está publicado en ogp.me y admite declarar el ancho y el alto de la imagen. El bloque JSON-LD, si existe, describe la entidad: organización, artículo, producto.

Las cabeceras se leen aparte, porque el código fuente no las muestra. curl -I https://tudominio.com/pagina devuelve el estado, el tipo de contenido, la política de caché y, cuando existe, un x-robots-tag que puede contradecir lo que dice el HTML. Una página con canonical correcta en el cuerpo y un x-robots-tag: noindex en la respuesta está bloqueada igual.

El estado también se lee ahí. Un 200 es una página que existe; un 301 o un 308 transfieren la dirección de forma permanente y conservan la autoridad acumulada; un 302 o un 307 lo hacen de forma temporal; un 404 no existe y un 410 declara que existió y se retiró. Los códigos están normalizados en el RFC 9110, y la distinción entre permanente y temporal no es un detalle: una redirección temporal mantenida durante meses deja a la URL vieja compitiendo con la nueva. El caso silencioso es el 404 blando: una página que responde 200 y muestra «contenido no encontrado». El visitante ve un error; el buscador recibe una respuesta correcta y tiene que deducir por el texto que la página ya no existe.

Capa 2: lo que el navegador ejecuta

Con F12, o Cmd+Option+I, se abre el inspector. Cuatro paneles resuelven casi todo:

• Elements. El DOM tal como quedó después de ejecutar JavaScript, con los estilos aplicados. Es la vista correcta para depurar maquetación y la incorrecta para leer metadatos, porque mezcla lo que el servidor envió con lo que el navegador añadió.
• Network. Cada petición con su tamaño transferido, su código y su lugar en la cascada. Activa «Disable cache» antes de recargar o medirás una versión que ningún visitante nuevo recibe. Ordena por tamaño y por tiempo: ahí aparecen la imagen de 3 MB que se ve pequeña en pantalla y la tipografía que retrasa el primer texto.
• Console. Errores de JavaScript y avisos del navegador. Un TypeError en un script de formulario explica por qué el botón de envío no hace nada aunque la página se vea terminada.
• Application. Cookies, almacenamiento local y caché. Sirve para comprobar si una sesión o un consentimiento se guardan donde deben.

Aquí se ve la diferencia entre lo que el servidor entrega y lo que el usuario recibe. Google puede ejecutar JavaScript, pero conviene no depender de ello para el contenido principal: su propia guía de SEO para JavaScript describe el renderizado como una segunda ola, con límites de tiempo y de recursos. Un producto que solo aparece después de tres clics y dos llamadas a la API es un producto que quizá nunca se indexe.

Capa 3: lo que el buscador tiene registrado

Esta capa se revisa fuera del navegador y es la que suele decidir el resultado.

Primero, robots.txt. Es un archivo en la raíz del dominio que indica a los rastreadores qué pueden pedir. Su especificación está en el RFC 9309, que aclara algo que se malinterpreta seguido: no es un mecanismo de control de acceso. Un Disallow no protege información, y peor, impide que el rastreador llegue a leer un noindex que está dentro de la página bloqueada. Para retirar una URL del índice se usa noindex; para proteger un archivo, autenticación.

Después, el sitemap. Es la lista de URLs que quieres que se rastreen, en XML, con fecha de modificación opcional. El protocolo en sitemaps.org fija los límites: hasta 50.000 URLs y 50 MB por archivo, con índices de sitemaps para volúmenes mayores. Solo deben entrar URLs canónicas y que respondan 200; un sitemap lleno de redirecciones enseña al buscador a desconfiar del archivo.

Luego, la consulta site: en Google. Sirve para una comprobación rápida —¿aparece esta URL?— y no como inventario: el número que muestra es una estimación y varía entre consultas.

Y por último, la herramienta que da la respuesta exacta: la inspección de URL de Search Console, documentada por Google en su centro de ayuda. Ahí se ve si la URL está indexada, cuál canónica eligió Google —que puede no ser la que declaraste—, cuándo fue el último rastreo y qué errores de datos estructurados encontró. Cuando una página no recibe tráfico, esta pantalla dice si el problema es de índice o de contenido.

Velocidad: el laboratorio y el campo no dicen lo mismo

Una medición de laboratorio se hace en un entorno controlado, con una conexión simulada y un dispositivo de referencia: es lo que entrega Lighthouse y lo que corre dentro de PageSpeed Insights. Una medición de campo viene de usuarios reales, con su red, su teléfono y su ubicación. Las dos sirven, pero no se comparan entre sí.

Los tres valores que resumen la experiencia están definidos en Core Web Vitals: el Largest Contentful Paint mide el momento en que se pinta el bloque principal y debe llegar a 2,5 segundos o menos; el Interaction to Next Paint mide la respuesta a una interacción y debe quedar en 200 milisegundos o menos; el Cumulative Layout Shift mide el desplazamiento inesperado de los elementos y debe mantenerse en 0,1 o menos. Los tres se evalúan en el percentil 75 de las visitas, no en el promedio.

El orden de arreglo que rinde: peso y formato de las imágenes, CSS y JavaScript que bloquean el renderizado, carga de tipografías, y espacio reservado para anuncios, videos y embeds. Casi nada de eso se resuelve desde el editor de contenido.

Lista de revisión antes de publicar

Esta es la secuencia que aplicamos a una página nueva antes de pasarla a producción. Doce puntos, cada uno con la falla que evita.

1. Título único en cada URL, con la intención de la página. Evita que dos páginas compitan por la misma consulta.
2. Descripción escrita a mano, entre 70 y 160 caracteres. Evita que Google invente el fragmento que ve el usuario.
3. Un solo H1 y jerarquía de H2 y H3 sin saltos. Evita que el orden de lectura se pierda en lectores de pantalla y en el índice.
4. Canónica absoluta que apunte a la propia URL, salvo duplicado deliberado. Evita que una versión con parámetros se indexe en lugar de la principal.
5. Robots coherente: sin noindex heredado y sin x-robots-tag que lo contradiga. Evita el bloqueo silencioso.
6. Estado 200 limpio y una sola redirección si la URL cambió. Evita cadenas de 301 que diluyen la señal.
7. Etiquetas sociales con imagen horizontal y sin texto pequeño. Evita que el enlace compartido aparezca sin imagen.
8. Enlaces internos con texto descriptivo y ningún enlace a una página eliminada. Evita mandar al visitante a un 404 desde el propio sitio.
9. Formulario probado de punta a punta: envía, confirma en pantalla y llega el correo. Evita descubrir el fallo una semana después con los leads perdidos.
10. Imágenes con alt, ancho y alto declarados. Evita saltos de maquetación mientras cargan.
11. HTML y datos estructurados válidos, comprobados en el validador del W3C. Evita errores de anidación que rompen el layout en un navegador y no en otro.
12. Prueba en un teléfono real, no solo en el emulador. Evita que la página funcione en escritorio y falle donde llega la mayoría del tráfico.

Inspeccionar la página de otro: qué se ve y qué no

De un sitio ajeno se puede leer el HTML, el CSS, el JavaScript servido al navegador, el peso de cada recurso, los scripts de terceros y el texto. Con eso se deduce la plataforma, el sistema de componentes, si hay un pixel de medición y qué tan pesada es la página en un teléfono.

No se ve el código del servidor, ni los datos de analítica, ni la conversión, ni la inversión publicitaria, ni el CRM. Tampoco se ve qué experimentos están corriendo. Cualquier conclusión sobre resultados a partir del código es una hipótesis.

Hay un límite práctico además del técnico: el contenido ajeno tiene derechos y los términos del sitio aplican. Se copian criterios —jerarquía, orden de secciones, longitud de un formulario— y no archivos, tipografías ni textos. Y el robots.txt del sitio se respeta igual cuando se revisa de forma automatizada.

Cuándo conviene que lo revise un equipo

Una página propia se inspecciona en una hora cuando hay una sola. El trabajo crece con el sitio: decenas de URLs, redirecciones de una migración, un formulario conectado a un CRM, contenido que se genera desde una base de datos. Ahí la inspección deja de ser una revisión puntual y se vuelve parte del proceso de entrega. Si lo que hace falta es montar el sitio desde cero, el punto de partida es qué es una página web y qué piezas la componen.

En Virtalio la revisión va dentro de la entrega: la primera versión de la mayoría de las piezas sale en menos de 48 horas, el branding completo y los videos toman de 3 a 5 días, las revisiones están incluidas y no se firman contratos. Si el sitio ya existe y pierde visitas o consultas, el punto de partida es la misma lista de arriba aplicada a las páginas que más tráfico reciben. Puedes ver cómo trabajamos una landing page y el sitio completo, o revisar la estructura de una página web y los elementos que hacen convertir una landing antes de encargar un rediseño.

Preguntas frecuentes

¿Puedo inspeccionar una página web desde el celular?

Puedes ver el código fuente y usar herramientas de escritorio remotas, pero el inspector completo vive en un navegador de escritorio. En Android, Chrome permite depurar un teléfono conectado por USB desde la computadora; en iOS el acceso es más limitado. Para una revisión en serio, usa escritorio y luego valida el resultado en un teléfono real.

¿Necesito instalar algo para inspeccionar una página?

No. El código fuente y el inspector ya están en el navegador, y las métricas de velocidad están en PageSpeed Insights, que corre en la web. Lo único que requiere cuenta es Search Console, y solo si el sitio es tuyo: la inspección de URL y los datos de indexación no son públicos.

¿Basta con revisar el código fuente?

No. El código fuente muestra lo que envió el servidor; no muestra lo que JavaScript construye después, ni las cabeceras, ni lo que el buscador tiene indexado. Una revisión que se queda en el código fuente deja fuera las tres causas más comunes de una página invisible.

¿Cada cuánto se revisa una página ya publicada?

Después de cada cambio de plantilla, de cada migración y de cada actualización del gestor de contenido, además de una revisión trimestral de las diez URLs con más tráfico. Los errores que más cuestan aparecen en esos tres momentos, no en el lanzamiento.

Fuentes

• RFC 9309, Robots Exclusion Protocol: rfc-editor.org/rfc/rfc9309.html
• RFC 9110, HTTP Semantics (códigos de estado): rfc-editor.org/rfc/rfc9110.html
• Google Search Central, SEO para JavaScript: developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics
• Google Search Console, inspección de URL: support.google.com/webmasters/answer/9012289
• Sitemaps XML protocol: sitemaps.org/protocol.html
• Core Web Vitals: web.dev/articles/vitals
• Chrome DevTools, Network panel: developer.chrome.com/docs/devtools/network/overview
• Chrome DevTools, overview: developer.chrome.com/docs/devtools/overview
• Lighthouse: developer.chrome.com/docs/lighthouse/overview
• The Open Graph protocol: ogp.me
• W3C Markup Validation Service: validator.w3.org