Todos los escenarios/ Desarrollador
Revisa un release en staging antes de publicarlo
Un release cambia una plantilla, el enrutado o el renderizado, y una semana después resulta que las categorías tienen noindex, el canonical apunta al staging y algunos enlaces llevan a un 404. Es fácil detectarlo antes de publicar si comparas el sitio antes y después.
- Quién
- Desarrollador, líder de equipo, QA, SEO técnico en un equipo de producto
- Sitio
- Una app o un sitio con releases frecuentes y un staging cerrado
- Qué duele
- Las regresiones de SEO se ven solo cuando cae el tráfico
- Qué necesitas
- Una revisión antes de cada release, sin abrir páginas a mano
Pasos en Molfar
Da a Molfar acceso al staging
En Ajustes › Peticiones, indica el usuario y la contraseña de la autenticación básica: cada petición lleva una cabecera Authorization. Ahí también van las cabeceras adicionales, como Accept-Language. Todo se queda solo en el archivo de ajustes de este ordenador.
Ajustes · Peticiones — documentación (en inglés)
En la captura: Inicio de un rastreo Define el alcance del rastreo
Los patrones de inclusión y exclusión, la profundidad, las URL con parámetros y los subdominios deciden qué direcciones puede visitar el rastreo, para revisar justo lo que toca el release.
Ajustes · Alcance del rastreo — documentación (en inglés)
En la captura: Estructura del sitio Rastrea el staging antes del release
El primer rastreo es el punto de partida. Mientras avanza ves sus etapas, las reglas de robots.txt y las últimas páginas leídas.
Rastreo — documentación (en inglés)
En la captura: Resumen tras un rastreo Tras el release: el informe Release check
Cuando el release llega al staging, vuelve a rastrearlo. El informe Release check responde qué cambió desde el último rastreo y si el release rompió algo.
Informes · Release check — documentación (en inglés)
En la captura: Historial de rastreos Revisa los cambios página a página
En Historial, elige el rastreo anterior (A) y el más reciente (B): qué cambió en los campos comparados y qué comprobaciones empeoraron.
Historial — documentación (en inglés)En la captura: Historial de rastreos Tras el deploy, revisa las páginas clave
URL audit revisa una dirección sin rastreo: estado, velocidad, qué cambia JavaScript en el title, el canonical, el meta robots y el H1, y capturas en escritorio y como Googlebot smartphone.
URL audit — documentación (en inglés)
En la captura: URL audit Delega la revisión en un agente
Por MCP, tu agente de IA puede iniciar un rastreo, esperar a que termine y comparar dos rastreos, todo en la ventana abierta de Molfar, donde ves cada paso.
MCP — documentación (en inglés)
En la captura: Conectar un agente de IA (MCP)
Lo que obtienes
Regresiones antes de publicar
Qué cambió el release en el staging, antes de que lo viera Google.
A frente a B
Cambios página a página y las comprobaciones que empeoraron.
Control tras el deploy
Las páginas clave de producción revisadas una a una.
Conviene saber
- Historial compara rastreos de un mismo sitio: el staging se compara con el staging, no con producción.
- Compara rastreos de tamaño parecido: un cambio de alcance o de límite entre ellos también parece un cambio del sitio.
- El interruptor de MCP puede estar bloqueado en tu cuenta; el candado dice qué lo abre.
Preguntas
- Nuestro staging está detrás de una VPN, no de una contraseña. ¿Funciona?
- Molfar rastrea desde tu ordenador, así que ve lo que ve tu ordenador con la VPN activada.
- ¿Se puede ejecutar en CI?
- Molfar es una app de escritorio, no una CLI para CI. Pero un agente de IA en tu ordenador puede lanzar la revisión por MCP.
- ¿El rastreo tocará producción?
- No, si el alcance del rastreo lo limita al staging. El ritmo de las peticiones se ajusta en los ajustes de rastreo.