Communitygithub.com

verificador-de-lanzamiento-web

Revisa un sitio web de pequeña empresa antes de su lanzamiento contra una lista de verificación de 15 puntos. Úsalo cuando un usuario pida auditar, revisar, verificar o lanzar un sitio web, o pregunte si un sitio está listo para publicarse. Proporciónale una URL, una carpeta de archivos del sitio o un enlace de demostración y devolverá un informe de aprobado/reprobado con evidencia y soluciones.

¿Qué es verificador-de-lanzamiento-web?

Esta habilidad para agentes de IA, llamada 'Verificador de Lanzamiento Web', automatiza la auditoría de sitios web de pequeñas empresas antes de su lanzamiento público. Evalúa el sitio contra 15 criterios esenciales, como página 404 personalizada, títulos únicos, meta descripciones, imágenes de previsualización social, texto alternativo en imágenes, enlaces internos, sitemap, robots.txt, HTTPS, protección contra spam, página de agradecimiento, Google Analytics, política de privacidad, FAQ y testimonios reales. El agente pide al usuario una URL en vivo, una carpeta de archivos o un enlace de demostración; luego examina cada punto, registrando evidencia concreta (página, archivo, línea, etiqueta o captura de pantalla) para cada aprobado. Si solo tiene una URL, marca los elementos no verificables como 'Necesita confirmación del cliente'. Finalmente, genera un informe estructurado con un veredicto (Listo / No listo / No listo - bloqueadores encontrados), una tabla de resultados, lista de correcciones priorizadas, pasos para el propietario, notas de diseño y elementos no comprobados. Está diseñado para pequeñas empresas con pocas páginas, formularios de contacto y visitantes que pueden leer inglés como segundo idioma. La habilidad sigue reglas estrictas: nunca inventa evidencia, testimonios o estadísticas; nunca marca como aprobado sin prueba; y considera bloqueadores críticos la falta de protección contra spam, confirmación de envío o testimonios falsos. Es compatible con cualquier agente que pueda ejecutar comandos de shell o acceder a archivos locales, como Claude Code, Cursor o Codex, y se integra con herramientas de línea de comandos para inspeccionar archivos y hacer peticiones HTTP.

Compatible con~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/mmsample97/website-launch-checker/tree/HEAD
Ver original→Ver todas las habilidades

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Documentación

Verificador de Lanzamiento Web

Propósito

Revisar un sitio web antes de que se publique, para que nada embarazoso salga a la luz. El verificador no rediseña el sitio. Comprueba la preparación, informa lo que falta y dice exactamente qué corregir.

Está diseñado para sitios web de pequeñas empresas: un negocio, unas pocas páginas, un formulario de contacto o captación de clientes potenciales, y visitantes que pueden leer inglés como segundo idioma.

Cómo usarlo

  1. Pide al usuario uno de estos:
    • Una URL en vivo
    • Una carpeta de archivos del sitio web
    • Un enlace de demostración o ensayo
  2. Si el usuario da solo una URL, di claramente qué no se puede comprobar desde fuera. No adivines esos elementos. Márcalos como "Necesita confirmación del cliente" en lugar de Aprobado.
  3. Revisa cada elemento de la lista de verificación a continuación, en orden.
  4. Para cada elemento, registra la evidencia: la página, archivo, línea, etiqueta o captura de pantalla donde lo viste. Sin evidencia no hay Aprobado.
  5. Termina con el formato de informe al final de este archivo.

La lista de verificación de lanzamiento de 15 puntos

Revisa los 15. No te saltes uno porque parezca pequeño.

1. Página 404 personalizada

  • Un visitante que escribe una dirección incorrecta ve una página 404 con la marca, no una página predeterminada del servidor o una página en blanco.
  • La página 404 enlaza de vuelta a Inicio y a Contacto.
  • Falla si no hay página 404, o si es la predeterminada.

2. Títulos de página únicos

  • Cada página tiene su propio <title>.
  • No hay dos páginas que compartan el mismo título.
  • Ningún título está vacío, y ningún título es solo el nombre del negocio en cada página.
  • Los títulos describen esa página en palabras sencillas.

3. Meta descripciones

  • Cada página principal tiene una meta descripción.
  • Cada descripción es única para esa página.
  • Cada descripción es un resumen breve y sencillo de lo que hay en esa página, sin relleno de palabras clave.
  • Falla si una página principal no tiene descripción.

4. Imágenes de previsualización social

  • Cuando el enlace del sitio se comparte en WhatsApp, Facebook u otras aplicaciones, muestra una imagen de previsualización, título y descripción adecuados.
  • Comprueba las etiquetas Open Graph (og:title, og:description, og:image) y que el archivo de imagen realmente exista.
  • Falla si la imagen de previsualización falta, está rota o es un marcador de posición.

5. Texto alternativo en imágenes

  • Cada imagen significativa tiene texto alternativo que describe la imagen en palabras sencillas.
  • Las imágenes decorativas pueden tener texto alternativo vacío, pero dilo.
  • Falla si las imágenes principales, fotos de productos o fotos del equipo no tienen texto alternativo.

6. Enlaces internos

  • Las páginas se enlazan entre sí de manera lógica: Inicio, Servicios, Acerca de, Contacto y cualquier página de servicio clave.
  • Haz clic o comprueba todos los enlaces internos. Ningún enlace va a una página que falta, un 404 o un marcador de posición como #.
  • Falla en cualquier enlace interno roto.

7. Sitemap y Google Search Console

  • Existe un sitemap.xml que enumera las páginas reales.
  • El sitio se ha enviado a Google Search Console, o se le ha dicho al propietario que este paso aún es necesario.
  • Solo con una URL no puedes probar el envío a Search Console. En ese caso, márcalo como "Necesita confirmación del cliente" y enuméralo como un paso del propietario. No lo marques como Aprobado por suposición.

8. robots.txt

  • Existe un archivo robots.txt en la raíz del sitio.
  • Permite las páginas que deberían encontrarse y no bloquea accidentalmente todo el sitio.
  • Falla si falta, o si bloquea todo.

9. HTTPS en todas partes

  • Cada página se carga a través de HTTPS, no HTTP.
  • Sin advertencias de contenido mixto: las imágenes, scripts y formularios también deben cargarse a través de HTTPS.
  • Falla en cualquier página HTTP o contenido mixto.

10. Protección contra spam en formularios

  • Cada formulario tiene protección contra spam, por ejemplo un captcha, honeypot o un servicio de formularios con filtrado de spam.
  • Falla si un formulario de contacto o captación de clientes potenciales no tiene protección alguna.
  • Si el sitio no tiene ningún formulario, márcalo como "No aplica aún" y agrégalo a la lista de correcciones como: "Necesario cuando se añada un formulario real." No lo marques como Falla por un formulario que no existe.
  • No envíes un formulario real para probar esto a menos que el usuario diga que puedes hacerlo. En su lugar, revisa el código o la configuración del formulario.

11. Página de agradecimiento después del envío

  • Después de que un visitante envíe un formulario, ve una página de agradecimiento o un mensaje de agradecimiento claro.
  • La página de agradecimiento confirma lo que sucede a continuación, por ejemplo "Responderemos por WhatsApp en un día laborable."
  • Falla si el formulario solo se recarga, se limpia o no muestra confirmación.
  • Si el sitio no tiene ningún formulario, márcalo como "No aplica aún" y agrégalo a la lista de correcciones como: "Necesario cuando se añada un formulario real." No lo marques como Falla por un formulario que no existe.

12. Google Analytics

  • Google Analytics, o una herramienta de análisis equivalente que el propietario haya elegido, está instalada en cada página.
  • Solo con una URL no puedes probar que el propietario puede ver los datos. Si no puedes verificar el acceso, marca esto como "Necesita confirmación del cliente" y enuméralo como un paso del propietario.
  • Analytics necesita la cuenta de Google del cliente. Dilo claramente. No afirmes que está hecho sin esa cuenta.

13. Política de privacidad, con nota de cookies

  • El sitio tiene una página de política de privacidad.
  • La política es real: indica qué datos recopila realmente el sitio, por ejemplo detalles del formulario, y cómo se utilizan.
  • Incluye una nota de cookies si se utilizan cookies o análisis.
  • Falla si la política es un texto genérico estándar que no coincide con este sitio, o si es texto copiado con el nombre de otro negocio.

14. FAQ

  • El sitio tiene una sección o página de FAQ.
  • Las preguntas son las que los clientes reales realmente hacen: rango de precios, ubicación, horarios, cómo reservar, qué llevar.
  • Falla si no hay FAQ, o si las respuestas son relleno vago sin información real.

15. Solo testimonios reales

  • Cada testimonio en el sitio es real.
  • Sin nombres de marcador de posición, sin reseñas inventadas, sin "Juan Pérez", sin citas genéricas presentadas como clientes.
  • Si un testimonio no se puede verificar, márcalo como Falla y di: elimínalo, o reemplázalo por uno real con permiso.
  • Si el sitio no tiene testimonios en absoluto, márcalo como "Falta" y di: no se encontró ninguno, y tampoco se encontraron nombres falsos. No lo llames "Falso". Una sección de testimonios faltante es un vacío que llenar, no un testimonio falso.
  • Un sitio con testimonios falsos es un fallo grave. No está listo, incluso si todo lo demás pasa.

Comprobaciones adicionales de diseño

Estas no son parte de los 15 puntos anteriores, pero repórtalas por separado como "Notas de diseño". No las mezcles en la puntuación de los 15 puntos.

  • Sin contenido generado por IA: sin degradados morados, sin título centrado más tres tarjetas idénticas como todo el diseño, sin diseño genérico repetido en cada sección.
  • Diseño premium, pulido, habitable: jerarquía clara, tipografía legible, fotos reales o detalles de proyectos reales cuando sea posible.
  • Los números son consistentes en todo el sitio: un formato, un sistema de tamaño. No mezcles "AED 500", "500 AED" y "500" para el mismo tipo de precio.
  • Los detalles del proyecto, cuando se usen, se muestran como estadísticas, no como afirmaciones vagas.
  • La información clave es fácil para un lector con inglés débil: oraciones cortas y simples, encabezados claros y datos de contacto fáciles de encontrar.

Reglas estrictas

  • Nunca marques Aprobado sin evidencia.
  • Nunca inventes un testimonio, una estadística, un recuento de clientes o una reseña.
  • Nunca digas que Search Console o Analytics está hecho sin el paso de la cuenta de Google del cliente.
  • Nunca digas que un sitio está listo si un formulario no tiene protección contra spam, confirmación de agradecimiento o testimonios falsos. Esos son bloqueadores. Un sitio sin ningún formulario es diferente: usa "No aplica aún" para las comprobaciones 10 y 11, no Falla.
  • Nunca uses un marcador de posición para llenar un vacío. Informa el vacío.
  • Mantén el informe en oraciones claras y cortas. El propietario puede no ser un lector técnico.

Formato del informe

Termina siempre con este formato, en este orden:

Informe de lanzamiento: [nombre del sitio o URL]

Veredicto: Listo / No listo / No listo - bloqueadores encontrados

Usa "Listo" solo si no hay Falla, o si los únicos elementos abiertos son pasos del propietario que el cliente ha confirmado que hará el día del lanzamiento. "No aplica aún" y "Falta" no bloquean por sí solos un veredicto de Listo, pero enuméralos como vacíos. De lo contrario, usa "No listo".

Resultados

#ComprobaciónResultadoEvidencia
1Página 404 personalizadaAprobado / Falla / Necesita confirmación del cliente / No aplica aún / Faltapágina o archivo
2Títulos de página únicos......
3Meta descripciones......
4Imágenes de previsualización social......
5Texto alternativo en imágenes......
6Enlaces internos......
7Sitemap y Search Console......
8robots.txt......
9HTTPS en todas partes......
10Protección contra spam en formularios......
11Página de agradecimiento después del envío......
12Google Analytics......
13Política de privacidad con nota de cookies......
14FAQ......
15Solo testimonios reales......

Correcciones, en orden de prioridad

  1. Bloqueador primero: [qué corregir, en qué página, en palabras sencillas]
  2. Siguiente corrección: ...
  3. ...

Pasos del propietario - necesita el cliente

  • [Por ejemplo: dar acceso a la cuenta de Google para Search Console]
  • [Por ejemplo: confirmar que los testimonios son reales y dar permiso para mostrarlos]
  • [Por ejemplo: escribir el texto real de la política de privacidad]

Notas de diseño

  • [Cualquier nota de la sección de Comprobaciones adicionales de diseño, o "Ninguna".]

Lo que no se comprobó y por qué

  • [Por ejemplo: No se pudo verificar el envío a Search Console solo desde una URL.]

Skills relacionados

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community