Define la tarea que falla antes de cambiar ajustes
Anota qué falla: resolver un nombre, abrir una página concreta o encontrarla en un buscador. Son tareas separadas. DNS devuelve registros asociados a nombres. HTTP describe un intercambio con un servidor web. La indexación describe lo que un motor ha procesado y conservado. Una observación correcta en una capa no demuestra éxito en la siguiente. Empieza con la tarea exacta y un ejemplo repetible, en lugar de cambiar DNS, robots y redirecciones a la vez.
Registra nombre afectado, URL completa, hora y fuente de la observación. Mantén tokens privados y datos de cuentas fuera de herramientas públicas. Anota dispositivo y red cuando el problema aparece en el navegador, y versión del sitio cuando sigue a una publicación. Busca un pequeño conjunto de observaciones comparables. Sin ese registro, un informe antiguo de indexación, una respuesta DNS en caché y un error actual pueden parecer un mismo evento aunque respondan a preguntas distintas.
| Capa | Pregunta | No demuestra |
|---|---|---|
| DNS | Nombre y tipo de registro | Servicio HTTP o indexación |
| HTTP | Respuesta final y declaraciones | Página indexada por el motor |
| Informe del motor | Observación registrada o en directo | Todas las rutas de visitantes funcionan |
Separa el nombre DNS de la URL de página
La pregunta DNS trata un nombre como example.com o www.example.com. No incluye https:// ni ruta de página. Esos dos nombres pueden tener registros diferentes y no son intercambiables. La pregunta HTTP incluye protocolo, host y ruta, y puede redirigir a otra dirección. Una portada correcta no demuestra que exista una ruta profunda. Escribe nombre DNS y URL completa en líneas separadas para enviar a cada herramienta el tipo de entrada adecuado y conservar la pregunta original.
Usa la consulta DNS con uno de sus siete tipos admitidos y el comprobador de indexación para una URL pública aceptada. Ninguno lee una página de cuenta autenticada. DNS utiliza Google como resolutor recursivo fijo; HTTP solicita desde el servidor de Savvy Toolkit. No reproducen todas las redes locales. Cambiar el resolutor de tu dispositivo es una operación de configuración distinta y no debe ser la primera respuesta solo para igualar dos observaciones. Conserva su configuración antes de considerar ese cambio.
Elige el registro que responde a la tarea
Para direcciones, revisa A para IPv4 y AAAA para IPv6 por separado. La falta de respuesta en uno no demuestra ausencia en el otro. Para correo, MX es pertinente, pero devolverlo no prueba un buzón. TXT puede contener varios registros independientes y no es un resultado general de validación. NS y SOA responden a otras preguntas de zona. La herramienta muestra datos recibidos, sin certificar toda la configuración del dominio ni descubrir todos sus subdominios.
Conserva código de respuesta y filas juntos. NOERROR sin respuestas del tipo elegido difiere de NXDOMAIN; SERVFAIL no significa inexistencia. Un fallo del proveedor no ofrece respuesta DNS válida que interpretar. Pueden aparecer alias junto al tipo solicitado, por lo que debes comparar nombre y tipo de cada fila. Un resultado truncado no es inventario completo. Tipos numéricos, valores y límites son pruebas; sustituirlos por una etiqueta simple de éxito puede cambiar lo que realmente muestran y ocultar información necesaria.
Utiliza TTL como observación de caché
TTL aparece en segundos. Un valor hipotético de 300 segundos equivale a cinco minutos, pero no establece una fecha límite mundial para un cambio. Un resolutor recursivo puede devolver respuesta en caché con TTL restante mientras otro ve datos distintos. La hora indica cuándo observaste, no cuándo cambió la configuración autoritativa. Conserva el registro anterior previsto y el nuevo previsto para comparar con un objetivo claro, sin deducir propagación completa a partir de una sola respuesta.
Repite nombre y tipo al comparar un cambio. Revisa aparte la configuración autoritativa del proveedor responsable mediante el acceso existente del propietario. No borres registros ni cambies varios resolutores solo porque una respuesta difiere. Savvy Toolkit no vigila finalización mundial ni guarda historial. Documentar un resolutor, una pregunta y una hora es útil; presentarlo como lo que ven todos los visitantes supera las pruebas. Guarda las observaciones anteriores para que una consulta nueva no sustituya su contexto.
Comprueba HTTP sin usar DNS como veredicto
Una dirección devuelta puede coexistir con una ruta inexistente. En un caso ficticio, DNS devuelve A para el host y la página solicitada responde HTTP 404. El nombre se resolvió, pero eso no crea la página. En otro caso ficticio, no hay respuesta AAAA mientras el navegador accede por IPv4. No son consultas reales de example.com. Demuestran por qué un registro vacío de un tipo y una petición fallida no deben combinarse en una afirmación de caída universal.
La consulta HTTP debe utilizar la URL pública exacta. Compara dirección final, código y hora con la observación del navegador. Una redirección puede cambiar host o ruta, y ahora importan sus declaraciones. Savvy Toolkit sigue redirecciones limitadas sin mostrar cada salto; no ejecuta JavaScript ni autentica cuentas. Un fallo desde su servidor puede tener una causa distinta del fallo del navegador. Conserva ambas perspectivas sin asignar causa antes de comprobarla. La primera tarea es alinear entradas y tiempos.
Separa código de respuesta y contenido útil
Un 200 indica que la solicitud recibió ese código correcto. Puede entregar un error o una estructura vacía. Examina el contenido para la tarea, no solo el código. Savvy Toolkit no puntúa contenido ni clasifica todos los soft 404. La inspección HTML está limitada por tamaño, tipo y codificación. No ver una declaración tras una inspección incompleta no demuestra que la respuesta completa carezca de ella. El aviso de límite debe acompañar a los campos obtenidos en cualquier comparación.
Ante un cambio de sitio, compara versión prevista con página enviada por el servidor y una vista renderizada pertinente. Alinea host y ruta finales. Una respuesta antigua o redirección a otra versión puede explicar discrepancias sin cambiar DNS. El propietario puede revisar registros de solicitudes reales con su acceso existente. No afirmes que Savvy Toolkit es Googlebot ni que su obtención prueba el trato de un rastreador real. Cada fuente de datos tiene un alcance que debe conservarse.
Mantén separados acceso y directivas de indexación
El comprobador muestra cabeceras y declaraciones HTML observadas y una decisión limitada de robots.txt. No conecta con el índice. Un noindex visible puede ser deliberado en revisión privada. Disallow controla acceso y no demuestra retirada de resultados; un rastreador bloqueado no lee el noindex de la página. Decide primero comportamiento público o privado previsto y revisa las declaraciones pertinentes. Quitar restricciones para obtener un informe aparentemente positivo puede contradecir el propósito del sitio o exponer páginas antes de tiempo.
La interpretación desconocida debe seguir desconocida. El analizador de prefijos literales no evalúa totalmente comodines, rutas escapadas ni todos los grupos. El archivo robots del origen final también puede ser inaccesible o incompatible. Los canónicos observados indican preferencia para duplicados; la herramienta no verifica su destino ni la elección del motor. Apuntar a otra página no es un error automático. Compáralo con el plan real de duplicados y conserva señales ambiguas para la inspección del responsable del sitio.
Consulta datos indexados y pruebas actuales aparte
En un sitio propio, utiliza herramientas verificadas del motor para consultar la información que ofrece. La Inspección de URLs de Google distingue datos indexados y prueba en directo. La página puede cambiar después de la observación indexada, por lo que debes alinear hora y dirección exacta. Savvy Toolkit aporta pruebas técnicas públicas, no esos informes conectados. Una búsqueda site: o fragmento guardado es otra observación y no sustituye con precisión al informe verificado disponible para esa URL.
Una obtención pública aparentemente correcta no garantiza rastreo, elección o conservación por el motor. Enviar la URL también es distinto de indexarla. Revisa tarea, enlaces contextuales descubribles y contenido original útil junto a las señales técnicas, sin convertir un número de palabras en objetivo de posicionamiento. La longitud de esta guía sigue el encargo del proyecto. No promete indexación ni tráfico y no justifica crear páginas repetidas que no aporten respuestas. El diagnóstico debe conservar la diferencia entre publicación y aceptación del buscador.
Resuelve diferencias cambiando una sola variable
Crea un registro con pregunta, entrada, fuente, hora, resultado y límite. Repite una pregunta sin cambios antes de editar configuración. Después modifica solo el ajuste responsable mediante el acceso habitual del propietario, conservando valor anterior y posibilidad de volver. Compara registro, publicación, redirección o directiva nuevos con su efecto previsto. Cambiarlos todos dificulta saber cuál importó y puede interrumpir servicios ajenos a la tarea fallida. Mantén cada decisión ligada a las pruebas que realmente la justifican.
Conserva privados los borradores mientras revisas ajustes de lanzamiento en un entorno aprobado. Un ejemplo local de metadatos correcto no es una publicación ni prueba propiedad del dominio. Antes de publicar más adelante, el propietario debe verificar respuestas alojadas y robots, canónicos y sitemap previstos. Las herramientas no despliegan ni editan el sitio. Este proceso produce observaciones repetibles y una siguiente acción limitada, no una marca verde que cubra todas las capas. Mantén explícitas las revisiones aún pendientes del entorno real.
Guarda un conjunto breve de pruebas
Para DNS, conserva nombre, tipo, resolutor, hora, código, filas pertinentes y truncamiento. Para HTTP, URL enviada y final, hora, código, declaraciones y límites. Para un informe del buscador, URL exacta, tipo de informe y momento bajo el acceso del propietario. No incluyas contraseñas, enlaces de sesión ni registros confidenciales en solicitudes públicas de corrección. Esos registros separados permiten a otra persona seguir la pregunta sin confundir un resultado actual con uno antiguo. El contexto hace reutilizables las observaciones.
Termina identificando la siguiente pregunta pendiente. Una discrepancia de registros corresponde al responsable DNS; una ruta final incorrecta, a enrutamiento o publicación; un canónico elegido por el motor, al informe verificado y al plan del sitio. Las herramientas ayudan a recopilar pruebas públicas limitadas para esas tareas. No sustituyen acceso al sistema responsable ni demuestran que se descartaron todos los fallos posibles. Mantén el límite junto al resultado al compartirlo, para que la siguiente acción siga el alcance comprobado.