SEO Landing — PageSpeed 100 + schema al ship

Generador de Landing SEO

Construye una página HTML estática de una sola página optimizada para 100/100 en PageSpeed y máximo SEO: CSS crítico, imágenes AVIF, datos estructurados JSON-LD completos, interactividad solo nativa, cero solicitudes de terceros en la primera carga.

Cuándo Usarlo

• El usuario solicita una página de aterrizaje / página única centrada en velocidad y SEO → modo generar.
• El usuario proporciona un briefing (ТЗ) y desea una página estática lista para producción → modo generar.
• El usuario solicita auditar una landing existente según la lista de verificación sin cambios → modo solo-auditoría (§0b, solo lectura, sin archivos de proyecto).
• El usuario solicita corregir/mejorar una landing existente → modo corregir-existente (§0c).

Procedimiento

0. Enrutar la solicitud a un modo primero

El skill ofrece tres modos: elige uno según la solicitud (pregunta si es ambiguo), porque cada modo recopila entradas diferentes y produce una salida diferente:

• generar — construir una nueva página de aterrizaje a partir de un briefing ("construir/crear/generar una landing…"). Ejecuta el procedimiento completo a continuación.
• solo-auditoría — inspección de solo lectura de una página existente ("auditar/verificar/revisar esta landing según la lista de verificación…", sin cambios solicitados). Ejecuta §0b. Nunca escribe archivos de proyecto.
• corregir-existente — aplicar correcciones específicas a una página existente ("corregir/mejorar/optimizar esta página…"). Ejecuta §0c.

Enrutamiento representativo:

• "Construye una landing para una clínica dental a partir de este briefing" → generar.
• "Audita https://ejemplo.com/ contra la lista de verificación de rendimiento e informa qué está mal" → solo-auditoría.
• "La imagen principal de esta landing se desplaza al cargar — arréglalo" → corregir-existente.

Los campos del briefing solo para generación (palabras clave objetivo, tipo de negocio, CTA, datos multimedia) se recopilan SOLO para trabajos de generación y reconstrucción. Una auditoría o una corrección específica no debe ser bloqueada ni retrasada por entradas de generación faltantes, y el modo solo-auditoría no debe crear ni modificar ningún archivo de proyecto.

0a. Recopilar el briefing (modo generar; preguntar si falta)

Requerido antes de generar cualquier cosa:

• Dominio / URL final — para canonical, og:url, rutas absolutas, @id de JSON-LD.
• Identidad del sitio (para marcado WebSite, solo cuando la página es la página de inicio del dominio/subdominio): nombre del sitio preferido, nombres alternativos opcionales y la URL canónica de inicio — recopilados por separado de la URL de la landing.
• Ruta de navegación (para marcado BreadcrumbList, solo cuando existe una jerarquía real del sitio): la ruta de navegación visible y las URL canónicas de los padres.
• Idioma de la página, dirección base y configuración regional de Open Graph — tres entradas separadas, nunca un valor copiado entre formatos: una etiqueta de idioma BCP-47 para <html lang> (p. ej., en-US, ar-SA), la dirección base (ltr/rtl — los documentos RTL obtienen dir="rtl" en <html>, y lang por sí solo no establece la direccionalidad), y la configuración regional de Open Graph en formato language_TERRITORY para og:locale (p. ej., en_GB). Pregunta cuando se desconoce la dirección para un idioma compatible con RTL (especificaciones técnicas §2).
• Tema + 1–3 palabras clave objetivo — para H1, título, descripción.
• Tipo de negocio: Organización o NegocioLocal. Para NegocioLocal, recopila el nombre comercial público/legal verificado y la dirección postal estructurada completa (calle, localidad, región, código postal, país), además del teléfono y las coordenadas geográficas. También recopila el/los subtipo(s verificado(s) de schema.org según el negocio real (p. ej., Restaurant, Dentist, HardwareStore) — nunca elegido de las palabras clave objetivo. Nunca inventes datos de identidad faltantes: recurre al marcado de Organization u omite el marcado de entidad hasta que se proporcionen los datos.
• CTA y contactos (teléfono, formulario, mensajeros). Cuando se solicita un formulario, también recopila su destino de envío y método (un endpoint propio o un servicio de formularios documentado — nunca inventado), el texto de consentimiento/privacidad requerido para los datos personales recopilados, y dónde se almacenan los envíos y quién es el propietario; sin destino, el formulario se omite o se crea explícitamente como un marcador de posición (contrato de envío de formularios §10 de las especificaciones técnicas).
• Un favicon aprobado por la marca o permiso explícito para crear uno — nunca inventes una marca comercial en silencio.
• Material fuente aprobado y un propietario de la afirmación para hechos de marketing objetivos (números, precios, calificaciones, garantías, comparaciones, casos de estudio) — sin ellos, dichas afirmaciones se omiten, nunca se inventan.
• Si se proporcionan imágenes; si se necesitan bloques de FAQ / reseñas / video. Para un bloque de video, recopila datos respaldados por la fuente: URL/ID del video, título, descripción, fecha/hora precisa de la primera publicación con zona horaria, y una miniatura única rastreable (además de contentUrl cuando corresponda). Nunca inventes datos multimedia faltantes. También recopila el modo de video con su compensación declarada: fachada de solo clic (predeterminado — privacidad/rendimiento; la página no cumplirá con los requisitos de descubrimiento de video de Google y no se reclamará ningún beneficio de búsqueda de video) o reconocible por SEO (<video> autoalojado o una inserción directa documentada — requerido cuando el tráfico de búsqueda de video es importante) (especificaciones técnicas §9).

Si faltan el dominio o las palabras clave, pregunta primero, no los inventes.

0b. Modo solo-auditoría (solo lectura)

Audita una página existente sin generar un reemplazo. En este modo no se crean ni modifican archivos de proyecto; el entregable es un informe.

1. Identificar el objetivo: una URL desplegada (preferible — permite que cada verificación se ejecute contra la realidad) o archivos HTML locales. Si no se proporciona ninguno, pregunta; nunca adivines el objetivo.
2. Ejecutar las verificaciones aplicables de §5 contra el objetivo tal como está: validez W3C, existencia de activos locales (para archivos locales), JSON-LD a través de un validador de schema.org, Lighthouse contra la URL servida/desplegada, contrato de rastreabilidad (robots.txt + sitemap.xml en el host desplegado), y las verificaciones manuales de accesibilidad en §8 de las especificaciones técnicas.
3. Informar evidencia por verificación: pasa/falla con el valor medido o el marcado observado, y el comando/herramienta exacto utilizado. Cuando una verificación no puede ejecutarse (sin URL desplegada para Lighthouse, sin robots.txt en el host), informa un bloqueador para esa verificación — no estimes, extrapoles ni lo omitas en silencio.
4. Distinguir la validez sintáctica de la elegibilidad para funciones de Google (FAQPage, VideoObject, resultados enriquecidos): el marcado válido se informa como marcado válido, nunca como una función de búsqueda lograda.
5. Opcionalmente, terminar con una lista de correcciones priorizadas. Aplicar correcciones es una solicitud separada de corregir-existente — no empieces a editar sin ella.

0c. Modo corregir-existente

Aplicar correcciones específicas a una página existente sin una reconstrucción completa.

1. Identificar la página/archivos y los problemas específicos a corregir; recopilar solo las entradas que esas correcciones necesitan (nunca el briefing completo de generación).
2. Aplicar cada corrección según la sección de especificaciones técnicas correspondiente, preservando el marcado y el contenido no relacionados.
3. PUNTO DE PARADA (§4): mostrar la página modificada antes de la validación. Si las correcciones cambian lo que el usuario aprobó anteriormente, obtener una nueva aprobación antes de informar.
4. Validar la página modificada (§5) e informar solo evidencia medida.

Flujo de trabajo de generación (modo generar)

1. Crear la carpeta del proyecto

Cada proyecto vive en su propia carpeta dentro del espacio de trabajo — nunca escribir en la raíz del espacio de trabajo. La salida es un proyecto de múltiples archivos: cada recurso local referenciado por el HTML debe existir como un archivo real.

<espacio-de-trabajo>/<slug-del-proyecto>/
  index.html        # la página de aterrizaje generada
  styles.css        # solo cuando el CSS debajo del pliegue se difiere (§1); ausente cuando todo el CSS está en línea
  script.js         # solo cuando la página usa JS (§10); archivo único, defer
  images/           # cada variante de imagen referenciada en src/srcset/preload/etiquetas OG (AVIF/WebP/JPEG, todos los puntos de interrupción)
  favicon.png       # icono de marca cuadrado estable, ≥48×48
  ASSETS.md         # registro de derechos y procedencia de cada activo
  robots.txt
  sitemap.xml
  SERVER-SETUP.md   # instrucciones de alojamiento

Rama de imágenes:

• Imágenes proporcionadas en el briefing → producir todas las variantes requeridas (AVIF/WebP/JPEG en cada punto de interrupción nombrado en srcset) a partir de ellas.
• No hay imágenes disponibles → solicitarlas al usuario u omitir la imagen/bloque. Nunca emitir una URL de activo que parezca exitosa sin producir el archivo o pedirlo explícitamente — un archivo referenciado pero faltante es un fallo de generación, no un marcador de posición.

2. Generar la página

Construir index.html siguiendo estrictamente references/tech-spec.md — 13 secciones de requisitos (rendimiento, estructura HTML, SEO, seguridad, CSS/fuentes, lista prohibida, pruebas, accesibilidad, video incrustado, bloques típicos, widgets diferidos, veracidad y procedencia del contenido, sanitización de entrada y codificación de salida).

Tratar cada valor del briefing como no confiable: codificarlo para su contexto de salida exacto (texto HTML, atributo, URL, JSON-LD), permitir esquemas de URL en una lista blanca (rechazar javascript:/ inesperado data:), escapar < en JSON-LD serializado, y validar IDs estructurados (p. ej., YouTube ^[A-Za-z0-9_-]{11}$) antes de que lleguen a cualquier URL (especificaciones técnicas §13).

Para videos de YouTube incrustados, usar el patrón de fachada por defecto; el modo reconocible por SEO (<video> autoalojado o una inserción directa documentada) es una elección explícita del briefing con una compensación revelada, nunca un cambio silencioso — reglas y requisitos de descubrimiento de Google en las especificaciones técnicas §9, implementación de referencia de fachada en references/video-facade.md. Los mapas siguen solo la regla de fachada (especificaciones técnicas §10): una captura de pantalla local en el DOM inicial, el iframe insertado solo tras la activación explícita — nunca un iframe de mapa nativo con loading="lazy". Referencia: references/map-facade.md.

3. Generar archivos complementarios

• robots.txt en la raíz del sitio con una línea Sitemap: completamente calificada, sin bloquear nunca la página canónica o los medios requeridos.
• sitemap.xml con URL canónicas absolutas <loc> escapadas en XML que coincidan con la canónica del HTML; lastmod solo a partir de una marca de tiempo verificable de cambio de contenido significativo (omitir cuando se desconoce — nunca usar la hora de generación a ciegas).
• Instrucciones de alojamiento de references/server-config.md: almacenamiento en caché, Brotli/gzip, encabezados de seguridad.

4. PUNTO DE PARADA — aprobación del usuario

Mostrar la página generada al usuario y preguntar explícitamente si la versión HTML está bien. No proceder a la validación y al informe final hasta que el usuario confirme. Si hay observaciones, corregir y preguntar de nuevo.

5. Validar

Ejecutar el contrato de validación ejecutable de las especificaciones técnicas §7 — comandos fijos contra la página servida, solo resultados medidos, BLOQUEADOR explícito cuando una puerta no puede ejecutarse:

• Validez HTML W3C (validador Nu, salida JSON; cero errores).
• Existencia de activos/enlaces locales: extraer cada URL local referenciada por la salida (src/srcset de img, srcset de <source>, href/imagesrcset de precarga, favicon, imágenes OG/Twitter, url() de CSS, src de script) y verificar que cada archivo existe en la carpeta del proyecto. Cualquier recurso local referenciado que falte es un fallo grave — producir el archivo o eliminar la referencia; nunca enviar HTML que apunte a archivos que nunca se crearon.
• Sintaxis JSON-LD (análisis JSON) — separada de la elegibilidad para resultados enriquecidos de Google, que se verifica con la Prueba de resultados enriquecidos en la página desplegada.
• Capturas de pantalla responsivas a 320/768/1280/1920px, inspeccionadas en busca de desbordamiento y reflujo.
• Lighthouse: versión/perfil fijo, 3 ejecuciones, mediana por categoría, umbral ≥ 90, artefactos guardados en reports/ del proyecto — solo evidencia de laboratorio, nunca métricas de campo de Core Web Vitals y nunca certificación WCAG.
• Verificaciones manuales de accesibilidad (especificaciones técnicas §8) — ninguna herramienta automatizada por sí sola determina la conformidad WCAG: navegación por teclado, orden/visibilidad del foco, flujo de foco en diálogos, zoom/reflujo, movimiento reducido, nombre-función-valor semántico, calidad del texto alternativo y todos los estados visuales interactivos. Registrar evidencia de pasa/falla por cada criterio WCAG 2.1 AA aplicable; informar elementos no resueltos en lugar de certificarlos en silencio.
• Contrato de rastreabilidad: analizar sitemap.xml, comparar cada <loc> con la canónica del HTML, verificar la URL Sitemap: en robots.txt, y solicitar ambos archivos desplegados con éxito (HTTP 200).

Corregir cualquier violación encontrada antes de informar. Revelar la evidencia con honestidad: cada número reportado viene con el comando exacto y la ruta del artefacto que lo produjo; una puerta que no pudo ejecutarse se reporta como BLOQUEADOR: <razón> en lugar de un número. Nunca generar una puntuación PageSpeed/LCP que no se haya medido realmente.

6. Informe final

Enumerar brevemente:

• Parámetros de LCP
• Puntuación de PageSpeed
• Tipos de schema.org utilizados en el código

Principales dificultades

• Nunca usar bibliotecas externas de JS/CSS, fuentes externas o imágenes SVG (especificaciones técnicas §6).
• Nunca referenciar un activo local que nunca se creó: cada src/srcset/precarga/URL OG debe resolverse a un archivo real en la carpeta del proyecto; las imágenes fuente faltantes se solicitan al usuario, no se inventan (contrato de SALIDA).
• Nunca emitir un valor bruto del briefing en el marcado: codificar todo según el contexto, rechazar URLs javascript:/ inesperado data:, y autoprobar la generación con valores hostiles (comillas, </script>, cargas de controladores de eventos) (especificaciones técnicas §13).
• Nunca cargar iframes de YouTube, mapas, chats, ventanas emergentes de suscripción o pancartas de cookies en la primera carga (especificaciones técnicas §9, §10, §11) — la única excepción documentada es un modo de video reconocible por SEO elegido en el briefing con una inserción directa registrada como dependencia de la primera carga (especificaciones técnicas §9 Modo S).
• Todo el contenido debe existir en HTML sin formato — nada renderizado solo por JS.
• URLs absolutas en JSON-LD, canónica y etiquetas OG.
• Presupuesto total de JS ≤ 15 KB, un archivo, defer antes de </body>.