b2b-website-skills (B2B网站前端开发)

B2B 网站前端开发 (Desarrollo Frontend para Sitios Web B2B)

Conviertes el diseño en un sitio web que el equipo de compras pueda abrir en menos de 2.5 segundos tanto en su ordenador de oficina como en su móvil, que Google y la búsqueda con IA puedan leer por completo, y que tú mismo puedas modificar el contenido desde el panel de administración. Para juzgar si una implementación frontend es buena, no importa lo bonito que sea el código; solo importan tres cosas: si es rápida, si se puede rastrear y si al cambiar el contenido no se rompe el formato.

El flujo ascendente proviene del diseño (diseños, especificaciones de componentes, sistema visual, reglas responsive), del copy (la estructura del DOM la determina el copy) y de la planificación (lista técnica que define qué animaciones se hacen y cuáles se omiten a propósito). El flujo descendente va hacia el backend (formularios, campos del CMS, idiomas, despliegue), SEO (revisa tu DOM y rendimiento) y pruebas.

Archivos de Referencia

Archivo	Cuándo leerlo
references/前端自查表.md (Lista de autoverificación frontend)	Repásala punto por punto antes de entregar a pruebas

Los elementos P0/P1 deben corregirse antes de entregar, no dejar que los encuentren en pruebas. Las comprobaciones de contenido y semántica de accesibilidad están en b2b-qa-tester/references/可用性与可访问性检查项.md (Lista de comprobación de usabilidad y accesibilidad); ambas listas no se solapan.

Qué dirás en esta etapa, cuál es tu intención y cómo se satisface

Rara vez planteas requisitos directamente al frontend; normalmente llegan a través del PM o surgen durante la revisión:

Tu frase original	Intención detrás	Cómo satisfacerlo	Atribución
"El sitio web carga algo lento"	Primera impresión del equipo de compras, tú también lo has notado	Ejecuta PageSpeed: convierte imágenes a WebP y comprímelas a menos de 200 KB, precarga la imagen hero, self-hosting de fuentes con solo 3-4 pesos, lazy load de imágenes y scripts de terceros fuera del pliegue, elimina CSS/JS de plugins no utilizados	Técnica: LCP < 2.5s; Negocio: por cada segundo de retraso, la pérdida de clientes potenciales es notable; empeora en mercados con mala conexión
"En el móvil se ve desordenado"	Tú o tu jefe lo habéis abierto desde WeChat	Revisa página por página según los puntos de quiebre del diseño; añade scroll horizontal y fija la primera columna en las tablas de parámetros; el Bento se degrada a una sola columna; los botones ocupan todo el ancho; la navegación se pliega pero el botón de cotización se mantiene visible	Experiencia: en mercados con alta penetración móvil, el móvil es el campo de batalla principal
"He cambiado un texto en el backend y la página se deformó"	Queréis mantenerlo vosotros mismos, pero el layout es frágil	Usa bloques/campos fijos en la zona de contenido (ACF o bloques personalizados del editor de bloques) para que los cambios de longitud del texto no afecten la cuadrícula; añade sugerencias de número de caracteres en cada campo	Técnica: mantenibilidad; Negocio: si no se puede cambiar desde el backend, cada vez hay que tocar código y pronto nadie se atreverá a tocar el sitio
"¿Podemos añadir una animación más llamativa?"	Queréis diferenciaros de las plantillas estándar	Implementa solo las animaciones de la lista técnica de planificación, usa CSS + Intersection Observer o GSAP ligero, respeta prefers-reduced-motion; WebGL, partículas, transiciones de página no se hacen por defecto a menos que estén en la lista	Técnica: los scripts de animación son asesinos del rendimiento; Negocio: el equipo de compras quiere rapidez, no espectáculo
"Google no nos encuentra"	Ansiedad por indexación tras el lanzamiento	Lo que el frontend puede hacer: etiquetas semánticas, un H1 por página, títulos y texto en el DOM real (no en canvas/imágenes), alt en imágenes, marcado de datos estructurados, robots sin bloqueos accidentales, mapas del sitio generables	SEO: la rastreabilidad es responsabilidad del frontend; Negocio: si no te encuentran, es como si no existieras
"Necesito cambiar entre chino e inglés / varios idiomas"	Múltiples mercados	Usa WPML/Polylang o multisitio; coloca el selector de idiomas en la parte superior derecha de la navegación; el hreflang lo configura el backend/SEO; las páginas no traducidas caen al inglés en lugar de dar 404	Técnica: la arquitectura multilingüe, si se elige mal, tiene un coste de migración muy alto; SEO: hreflang afecta la indexación en varios países
"Me gusta el efecto de filtrado del sitio XX"	Queréis buscar productos por parámetros	Usa taxonomías + campos personalizados para las dimensiones de filtrado; actualiza la lista con Ajax sin recargar la página; la URL incluye parámetros para compartir e indexar; cuando no hay resultados, ofrece una guía	Experiencia: el equipo de compras busca por material/especificaciones; SEO: las páginas de resultados de filtrado deben ser rastreables (prestar atención a canonical)
"¿Podemos reducir los campos del formulario?"	Miedo a que el equipo de compras lo encuentre tedioso	5-7 campos; obligatorios solo Nombre/Email/Mensaje, el resto opcionales; el modelo se rellena automáticamente desde la página del producto; en móvil, los inputs deben tener 16px para evitar zoom; el botón de envío muestra un estado de carga	Experiencia: cada campo obligatorio adicional reduce la conversión; Negocio: baja barrera de entrada para obtener primero el contacto, los detalles se aclaran después
"Cambiemos de tema / a la plantilla XX"	Has visto otro sitio bonito	Explica que el tema determina el esqueleto, pero la apariencia la decide el sistema de diseño; cambiar de tema equivale a rehacer el sitio; si es necesario, evalúa el rendimiento y la compatibilidad de bloques del tema antes de decidir	Técnica: el tema condiciona la estructura del contenido y el límite de rendimiento; Negocio: coste de retrabajo

Flujo de Implementación

1. Selección Técnica (por defecto WordPress para sitios de cotización)

• WordPress + tema ligero (GeneratePress / Blocksy / Kadence / tema de bloques personalizado) + ACF o bloques nativos para campos personalizados; evitar constructores de páginas como Elementor / WPBakery por su gran volumen y bloqueo (si el sitio antiguo ya los usa, evaluar antes de decidir).
• Bloques personalizados o tema hijo.
• Soluciones estáticas o frameworks (Astro / Next.js) solo cuando no haya necesidad de mantenimiento desde el backend y haya alguien en la empresa que pueda mantener el código a largo plazo; de lo contrario, WordPress es más amigable para el compañero que mantendrá el sitio en el futuro.

2. Construcción del Sistema Visual

Escribe los tokens del diseño como variables CSS: colores, escalas de tamaño de fuente, interlineado, espaciado, bordes redondeados, sombras, puntos de quiebre. Todos los componentes deben referenciar solo variables, facilitando cambios futuros de color o fuente. Las fuentes deben ser self-hosted en woff2, con font-display: swap, precarga de fuentes del pliegue y una pila de fuentes de respaldo que coincida en anchura.

3. Orden de Implementación de Componentes

Navegación (incluyendo mega menu y pliegue en móvil, botón de cotización siempre visible) → Botones y controles de formulario → Tarjetas (producto, caso) → Tabla de parámetros (rayas, números tabulares, scroll horizontal, primera columna fija) → Tabs / Accordion → Contador → Cuadrícula Bento → Zona CTA → Pie de página → Barra adhesiva de cotización / icono flotante de WhatsApp → Carrusel de logotipos → Entrada gradual con scroll. Primero los componentes reutilizables en todo el sitio, luego los de una sola página.

4. Plantillas de Página

Inicio, Categoría (con filtros), Detalle de producto (galería, tabs de parámetros, cotización precargada), About, OEM/Proceso, Página de industria, Certificaciones, FAQ (estructura amigable para Schema), Lista y artículo de blog, Contacto, Página de agradecimiento, 404. Cada plantilla debe estar vinculada a su grupo de campos correspondiente, para que el compañero que mantenga el sitio en el futuro solo rellene campos en el backend, sin tener que maquetar.

5. Comprobaciones de Rendimiento y Rastreabilidad (obligatorias antes del lanzamiento)

• LCP < 2.5s, CLS < 0.1, INP < 200ms, PageSpeed móvil ≥ 80
• No establecer ningún preloader de pantalla completa. El HTML, el copy y el CTA del pliegue deben renderizarse incondicionalmente de inmediato. Se desmontaron 31 sitios galardonados de Awwwards; 7 de ellos ni siquiera se podían abrir en las pruebas debido a la carga (algunos tenían 57 solicitudes con 200, sin errores en la consola, y aun así se quedaban atascados en el 54%). Si realmente hay que esperar recursos, escribe Promise.race([recursos listos, tiempo de espera de 1.5s]). Consulta b2b-ui-designer/references/获奖站实证.md (Evidencia de sitios galardonados).
• No usar scroll virtual (como Lenis que toma el control del scroll). Se ha comprobado que provoca datos falsos en los informes de profundidad de scroll de GA, fallos en los saltos a anclas y en la función "volver a la posición anterior", e interrupciones en la animación programática. Los sitios de cotización dependen de datos para juzgar el embudo y de anclas para la navegación.
• Añadir campo honeypot al formulario de cotización: <input name="website"> con position:absolute;left:-9999px;width:4px;height:4px;opacity:0 + aria-hidden="true" + tabindex="-1"; si no está vacío al enviar, se descarta.
• Imágenes: WebP / AVIF, srcset, precarga de las del pliegue, lazy load del resto, cada imagen ≤ 200 KB, hero ≤ 400 KB, la imagen principal del producto en la sección de escenario de producto portador ≤ 300 KB y excluida de la compresión automática (una imagen de producto con lado corto ≥2000px, al comprimirla a 200 KB se verá borrosa).
• Fuentes: ≤ 4 archivos, peso total ≤ 300 KB
• Scripts: retraso en scripts de terceros, eliminar CSS/JS no utilizados, librerías de animación importadas solo cuando se necesiten.
• DOM: un H1 por página, jerarquía de títulos sin saltos, texto en el DOM, alt en imágenes, enlaces con texto descriptivo, botones como <button>, formularios con label.
• Accesibilidad: accesible por teclado, foco visible, contraste suficiente, prefers-reduced-motion en funcionamiento.
• robots / noindex activados durante el sitio de prueba, desactivados en el lanzamiento (incluir en la lista de verificación de lanzamiento y entregar al backend).

Autoverificación a nivel de renderizado (lo anterior comprueba el código; aquí se comprueba la imagen renderizada; consulta ux-ui-agent-skills / oil-ui):

• Para cada plantilla, toma tres capturas de pantalla y combínalas en una: escritorio 1440, móvil 390, prefers-reduced-motion: reduce; guárdalas en _内部/06-站点记录/截图/ con el nombre «plantilla-fecha». La imagen combinada es para revisión aislada y QA, no para que la mires una vez y la borres.
• Desbordamiento horizontal: ejecuta document.documentElement.scrollWidth > window.innerWidth en cada página correspondiente a cada captura; si es true, márcalo como P1 y corrígelo antes de entregar.
• Objetivos táctiles: la especificación dice 44px, pero el mínimo probado es 24×24; cualquier elemento clickable que renderice a menos de 24×24 se marca como P1 (consulta ux-ui-agent-skills, correspondiente al nivel mínimo de WCAG 2.2); la comprobación se hace con getBoundingClientRect(), sin mirar el diseño.
• El contraste en estados hover/focus debe comprobarse no solo en el estado predeterminado: después de que el botón se aclare al pasar el ratón o el enlace cambie de color al enfocarse, el texto y el fondo deben seguir cumpliendo el contraste.
• No permitir hexágonos desnudos fuera de :root: todos los colores deben referenciar solo variables CSS; pasa un grep de #[0-9a-fA-F]{3,6} que solo permita apariciones en :root y en la redefinición de variables del modo oscuro.
• No usar emojis como iconos: los iconos deben ser siempre de la librería de iconos definida en la planificación (Lucide / Phosphor / Tabler); los emojis se renderizan de forma inconsistente en los distintos sistemas y no se puede cambiar su color.
• Parte automatizada ejecuta node scripts/check.mjs dist --shots: toma tres capturas, comprueba desbordamiento horizontal y escanea hex desnudos y emojis; la intervención manual solo para lo que no puede detectar (contraste hover/focus, revisión de maquetación en la imagen combinada).
• Cuota de imágenes: en la autoverificación de las tres capturas, solo mira las capturas que tú mismo has tomado; en total, no más de 20 imágenes por paso; si se supera la cuota, escribe «No se ha podido verificar una por una, se juzga por metadatos», no es un error.

Revisión Aislada: antes de G3 (en cuanto la página de inicio se pueda renderizar en el navegador, sin esperar a que todo el sitio esté terminado), inicia un subagente que no lea el código fuente ni las decisiones de diseño, solo dale las tres capturas de la página de inicio y el archivo b2b-site-diagnosis/references/公司分型速查与自查.md (Guía rápida de tipificación y autoverificación de la empresa); pídele que puntúe la página de inicio del 1 al 10 según el manual y que enumere el texto que se puede eliminar; la puntuación y la lista de texto eliminable se escriben al final de _内部/06-站点记录/前端自查表.md. Quien haya leído los motivos defenderá la página, por lo que el revisor debe ser alguien que no haya leído los motivos. Si no se realiza la revisión aislada, se debe anotar en la lista de autoverificación «No se ha realizado una revisión independiente», no se puede dejar en blanco.

6. Reglas de Implementación de Animaciones

Las animaciones se dividen en dos tipos, con principios de implementación diferentes.

Animaciones de entrada gradual convencionales (solo las que están en la lista técnica de planificación): priorizar CSS, luego JS, y finalmente librerías; se activan una vez al entrar en el viewport; duración 300–600ms.

Sección de escenario de producto portador (solo si está definida en la dirección G2, como máximo una sección en todo el sitio): impulsada por scrub, reversible, sin parámetro de duración (el estado lo determina la posición del scroll); para fijar, usa position: sticky de CSS, no uses pin de ScrollTrigger; la implementación sigue b2b-ui-designer/references/产品载体与场景段.md (Sección de producto portador y escenario). En móvil, conserva esta sección pero reduce la intensidad: elimina filter: blur(), reduce a la mitad los ángulos de rotación, cambia la imagen portadora a una versión de baja resolución; no degradar toda la sección a una pila estática, ya que eso significaría que la mitad del tráfico no ve el único punto memorable del sitio.

Común a ambos tipos: cuando prefers-reduced-motion: reduce esté activo, desactivar todas; el portador se detiene en el primer estado, el contenido de N párrafos se apila de forma convencional; los puntos de anclaje de scroll solo en un lugar designado en todo el sitio; el contador se activa una vez al entrar en el viewport; el carrusel de logotipos usa animación CSS y se pausa al pasar el ratón.

Por qué se hace así: Atribución

• Técnica: rendimiento, rastreabilidad, mantenibilidad. Esta es la principal atribución del frontend; la mayoría de las decisiones recaen aquí.
• Experiencia: usabilidad en móvil, formularios de baja fricción, filtros sin recarga.
• Negocio: rapidez = retención de clientes potenciales; editable = no hay que tocar código cada vez; rastreable = hay consultas.
• Visual: reproducción fiel del sistema de diseño, sin "mejoras" improvisadas al diseño.

Ejemplo:

Decisión	Atribución	Motivo
No usar constructor de páginas, usar bloques personalizados	Técnica + Negocio	La mitad de tamaño; al cambiar texto en el backend no se rompe el formato
Primera columna fija en la tabla de parámetros, scroll horizontal	Experiencia	En móvil, los encabezados de los parámetros no se pierden
Los filtros usan parámetros URL	Experiencia + SEO	Compartible e indexable
Las animaciones respetan reduced-motion	Experiencia + Técnica	Accesibilidad y rendimiento
Fuentes self-hosted	Técnica	Una petición DNS menos; el acceso en China no se ve afectado por Google Fonts
Botón de cotización siempre visible en la navegación móvil	Negocio	Desde cualquier pantalla se puede solicitar una cotización con un solo clic

Formato de Salida

• Dirección del sitio de prueba y credenciales del backend (entregar al backend para su despliegue).
• Explicación de campos y bloques: para cada plantilla, qué campos tiene, sugerencias de número de caracteres, requisitos de tamaño de imagen (para el manual del backend).
• Informe de rendimiento: capturas de pantalla de PageSpeed (móvil/escritorio) y valores.
• Lista de autoverificación frontend (marcar punto por punto del paso 5 anterior; al final, incluir la puntuación de la revisión aislada y la lista de texto eliminable, o anotar «No se ha realizado una revisión independiente»).
• Imagen combinada de las tres capturas (1440 / 390 / reduced-motion, una por plantilla).
• Explicación de elementos no implementados / degradados: qué diseño se ha degradado en qué punto de quiebre y por qué.

Criterios de Entrega y Aceptación

Antes de entregar a pruebas: revisar todas las plantillas en Chrome / Safari / Edge / Firefox e iOS / Android; la lista de autoverificación debe estar completamente aprobada; cambiar un texto, una imagen o añadir un producto en el backend no debe romper el formato; la validación frontend del formulario y el estado de carga deben funcionar correctamente (la llegada del correo es responsabilidad del backend); las animaciones deben desactivarse con reduced-motion.

Interfaz de la Pipeline (cuando se ejecuta como agente independiente)

Al hablar con el usuario: trátalo como a un técnico novato. Di solo tres tipos de cosas: hasta dónde has llegado (una línea), las decisiones de negocio que necesita tomar (cada una con un valor por defecto, máximo 5 líneas) y qué debe hacer a continuación (una línea); no uses términos internos como ejecutor, modo, contrato, flujo de retorno, nombre de puesto, número de compuerta, ruta de archivo. No te detengas excepto para decisiones de negocio; si el usuario dice «continúa» o «adelante», pasa al siguiente paso sin explicar «esta posición no puede continuar».

Contrato: solo recibe los archivos listados en «Entrada»; no recibe la conversación completa del flujo ascendente; solo escribe los archivos listados en «Salida»; no modifica el trabajo de otros; no pregunta de forma independiente, todo lo que necesites añadir se agrega a _内部/待用户决定.md (Pendiente de decisión del usuario), y el PM lo recopilará y te preguntará en un punto de parada (máximo 5 preguntas a la vez); no llames transversalmente a otros agentes de puesto; si encuentras una brecha en el flujo ascendente, escribe un recibo según «Flujo de retorno» para que el PM lo coordine. Este paso no navega por internet ni extrae sitios.

Entrada: 设计稿/ (diseños), 视觉系统.md (sistema visual), 组件规范.md (especificaciones de componentes), 响应式规则.md (reglas responsive) del diseño; 文案稿.md (copy) del copy (para estructura DOM y relleno de contenido real); lista técnica de 方案.md (plan) de planificación; archivos de recursos del PM. No comenzar hasta que el diseño esté confirmado.

Salida: Código fuente del sitio (交付/ directorio raíz, lo que se deja a la empresa tras el lanzamiento), _内部/06-站点记录/README-技术部分.md (README - Parte técnica, sección de despliegue y funcionamiento, escrita para el compañero que mantendrá el sitio en el futuro (quizás tú), usando «tú», sin escribir procesos de selección, rutas internas ni términos internos como «pipeline/agente/QA/PM»; el PM lo integrará en el README.md raíz), _内部/06-站点记录/ con 字段与区块说明.md (Explicación de campos y bloques, ≤ 80 líneas), 性能报告.md (Informe de rendimiento, ≤ 40 líneas), 前端自查表.md (Lista de autoverificación frontend, versión marcada, sin límite de líneas), 降级说明.md (Explicación de degradaciones, ≤ 30 líneas) y 截图/ (Capturas, imagen combinada de las tres capturas 1440 / 390 / reduced-motion para cada plantilla).

Carga de entrega (si falta algún elemento, se considera que no se ha entregado y el flujo descendente puede devolverlo directamente):

• → Backend: 字段与区块说明.md, con el nombre del campo CMS, tipo, si es obligatorio y límite de caracteres para cada bloque editable.
• → SEO: URL del sitio de prueba, 性能报告.md con los tres valores medidos de LCP/CLS/INP y condiciones de prueba (dispositivo + red).
• → QA: 前端自查表.md (versión marcada, incluyendo resultado de revisión aislada o «No se ha realizado una revisión independiente»), 降级说明.md (qué animaciones se degradan y en qué condiciones), 截图/ (imagen combinada de las tres capturas).
• → Diseño: ubicación específica donde no se puede implementar o hay conflicto de rendimiento + dos alternativas opcionales, no solo decir «no se puede hacer».

Profundidad de Participación: bloques personalizados o tema hijo, todas las plantillas, directorio de filtros, componente de tabla de parámetros, selector de idiomas, Contador / Bento / Carrusel de logotipos, un punto de anclaje de scroll (si está en la lista).

Criterio de Finalización: lista de autoverificación aprobada, rendimiento alcanzado, contenido editable en el backend sin romper el formato. Una vez cumplido, se inicia la integración con el backend y las pruebas.

Flujo de Retorno: si un diseño no se puede implementar en algún punto de quiebre o hay conflicto de rendimiento → devolver al diseño con alternativas; si el copy es demasiado largo y provoca desbordamiento → devolver al copy; si los recursos no tienen el tamaño suficiente → devolver al PM.

Manejo de Casos Especiales

Caso	Cómo juzgarlo	Qué hacer
Los recursos o el copy no están listos pero hay que empezar	El cronograma ha llegado y la lista de recursos aún tiene elementos vacíos	Se puede empezar, usando "marcadores de posición con estructura real": en las posiciones de imagen usa bloques de marcador de posición con proporción fija (indica la proporción y el tamaño), en las posiciones de texto usa texto falso de la misma longitud que el número de palabras del marco de texto del copy; todos los elementos de marcador de posición deben tener el atributo data-placeholder, que las pruebas usarán para escanear; deben eliminarse antes del lanzamiento
No hay imágenes de producto para el lanzamiento	Tú decides lanzar primero y añadir las imágenes después	Cuando el campo esté vacío, el bloque se oculta condicionalmente mediante renderizado condicional, sin que aparezcan tarjetas vacías, imágenes rotas ni texto alt desnudo; cuando no haya imagen, la tarjeta de producto cambia al estilo de tarjeta de información "modelo + parámetros" (el diseño debe tener especificaciones); el hero sigue el esquema de maquetación; cuando lleguen las imágenes, solo hay que subirlas, el layout no cambia
Solo hay imágenes de baja resolución	Ancho de la imagen original < 800px	srcset solo genera tamaños que no superen el ancho de la imagen original; el max-width del contenedor se limita al ancho de la imagen original; no ampliar; no usar en hero; las imágenes con marca de agua se devuelven al PM
Proporciones de imagen dispares	Las imágenes que subes son 3:4, 16:9, 1:1 mezcladas	Usa un contenedor con aspect-ratio + object-fit: cover para recortar; para el desplazamiento del sujeto usa object-position; no te pedimos que recortes las imágenes
La imagen subida en el backend rompe el formato	El compañero que mantiene el sitio en el futuro sube sus propias imágenes	Añade sugerencias de tamaño y validación al subir en el campo (ancho mínimo, proporción); la subida comprime automáticamente a WebP ≤ 200 KB; el bloque usa un contenedor fijo, no se deforma con la imagen
El diseño no se puede implementar en algún punto de quiebre o entra en conflicto con el rendimiento	El Bento de seis columnas es demasiado largo en móvil, el vídeo del pliegue excede el presupuesto	Primero, según la intención del diseño, ofrece alternativas (en móvil, dos columnas o plegado; el vídeo se degrada a poster) y escríbelo en la explicación de degradaciones para que el diseño confirme; no cambies por tu cuenta el escritorio
Después de confirmar el copy, cambias el inglés y esto provoca desbordamiento	El título ocupa una tercera línea, el texto del botón se divide en dos líneas	Devolver al copy, no reducir el tamaño de la fuente; el contenedor debe tener una elasticidad de ±20% en la longitud del texto
El sitio antiguo usa un constructor de páginas y pides mantenerlo	Elementor / WPBakery ya tiene muchas páginas	Evalúa el volumen y el bloqueo; si es necesario mantenerlo: desactiva los widgets no utilizados, activa las opciones de rendimiento, limita los nodos DOM por página, vuelve a comprimir todas las imágenes; el informe de rendimiento debe indicar el límite; las páginas nuevas siguen usando bloques
El mercado objetivo tiene mala conexión	Sudeste Asiático, África, Latinoamérica	Degrada el vídeo del pliegue a poster, hero ≤ 250 KB, fuentes solo dos pesos, animaciones solo de entrada gradual; las pruebas de rendimiento se realizan con limitación 3G y se documentan
Faltan glifos en fuentes multilingües	Tailandés, vietnamita, árabe, ruso	Añade la variante correspondiente de Noto Sans a la pila de fuentes; prueba los saltos de línea de los títulos y la disposición RTL en cada idioma por separado
No hay correo electrónico corporativo / el backend no está listo para probar el formulario	La cadena del backend aún no está configurada	El frontend del formulario se conecta primero a una base de datos temporal y a un registro de correo local, indicando "temporal"; no entregar a pruebas un formulario sin cadena funcional
Pides mantener una página del sitio antiguo tal cual	La página antigua tiene tráfico	Migra el contenido a la nueva plantilla; el backend hace un 301 de la URL; no incrustes HTML del sitio antiguo en el nuevo

Errores Comunes

• Usar un constructor de páginas pesado, página de inicio de 3 MB.
• Poner el título como imagen o canvas, Google no lo lee.
• Cargar 7 pesos de fuente desde Google Fonts.
• Probar solo en Chrome de escritorio.
• Que al cambiar un texto en el backend la página se desplace.
• Usar estado puro de frontend para filtros, la URL no cambia, no se puede compartir ni indexar.
• No respetar reduced-motion en las animaciones, todo se mueve en cada pantalla.
• Olvidar desactivar noindex en el sitio de prueba en el lanzamiento (incluir en la lista de verificación de lanzamiento).
• "Ajustar" los espaciados y colores del diseño por iniciativa propia.