Redacción de Texto para Sitios Web
Un sitio web debe hacer que la persona adecuada reconozca su situación, entienda qué hace el producto y sepa qué hacer a continuación.
Principio: Escribe desde la realidad del visitante hacia afuera, no desde la lista de características del producto hacia adentro. El texto debe sonar como una persona que entiende el trabajo, no como un especialista en marketing explicando cómo funciona el marketing.
Esta es una habilidad de escritura y diseño de información, no un detector de IA ni una fórmula rígida de conversión. No optimices para sonar "humano" a costa de la verdad, la accesibilidad o la precisión.
Etiquetas de evidencia
Versión 1.1. Las etiquetas aparecen solo en afirmaciones de efectividad: declaraciones de que algo mejora el reconocimiento, la comprensión, la confianza o la conversión. Las obligaciones y los pasos del flujo de trabajo no están calificados.
[E]evidencia directa verificada: estudio revisado por pares o prueba documentada que mide el efecto declarado, con tamaño del efecto y limitaciones.[P]práctica plausible: útil sin evidencia directa medida para esta audiencia.[S]preferencia de estilo editorial. Los elementos de estilo se califican enreferences/evidence.md; no están etiquetados en línea en esta habilidad.
Ninguna regla de esta habilidad es [E] para la conversión de páginas de aterrizaje. Trata los consejos de conversión como una hipótesis a probar en el sitio real y nunca prometas un incremento sin medición. Las afirmaciones de efectividad sin etiqueta aquí son prácticas de asesoramiento en [P]; las obligaciones y los pasos del flujo de trabajo no están calificados. La clasificación completa por elemento, las fuentes y los experimentos candidatos están en references/evidence.md.
Reglas no negociables
- Lidera con relevancia. Nombra un problema, tarea o resultado específico que el visitante previsto reconozca. Menciona el producto lo suficientemente rápido para que el visitante entienda qué se ofrece.
[P] - Explica la conexión causal. Muestra qué hace realmente el producto para ayudar. No reemplaces mecanismos con promesas.
[P] - Suena natural. Prefiere lenguaje cotidiano, sustantivos específicos y verbos comunes. Mantén la precisión técnica para audiencias técnicas.
- No uses guiones largos ni cortos en el texto propuesto para el sitio web. Reemplázalos con un punto, una coma, dos puntos o una reformulación natural. Conserva la puntuación original al citar material fuente. Si el usuario solicita explícitamente un estilo diferente, síguelo.
- Sin emociones fabricadas. No inventes dolor, urgencia, miedo, estadísticas, pruebas sociales, resultados o características.
- Sin plantilla obligatoria. No le des a cada sitio web la misma secuencia de Problema / Agitación / Solución / Características / Testimonios / CTA. Elige las secciones según lo que los visitantes necesiten para decidir.
- No reescribas solo por reescribir. Si el original es más claro, consérvalo. Haz el cambio más pequeño que mejore la comprensión.
Decide qué necesita entender el visitante
Antes de editar, inspecciona el material que el usuario proporciona: página en vivo, captura de pantalla, texto actual, resumen o código fuente. Determina:
- Audiencia: ¿Quién necesita esto? Usa un rol o situación reconocible en lugar de "todos".
- Desencadenante: ¿Qué evento los lleva a buscar ayuda ahora?
- Tarea: ¿Qué están tratando de lograr?
- Obstáculo: ¿Por qué el enfoque actual falla o requiere demasiado esfuerzo?
- Costo: ¿Qué significa realmente el obstáculo para ellos? Tiempo perdido, preguntas sin respuesta, confusión, riesgo o dinero. Solo incluye consecuencias respaldadas por el contexto.
- Cambio deseado: ¿Qué mejoraría su próxima hora, día o flujo de trabajo?
- Mecanismo del producto: ¿Cómo causa el producto ese cambio, en términos concretos?
- Evidencia: ¿Qué está demostrado, documentado o verificado?
- Acción: ¿En qué pueden hacer clic, probar, solicitar o leer a continuación?
Mantén una distinción clara entre hechos y suposiciones. Si faltan detalles, usa un lenguaje conservador y etiqueta las suposiciones importantes en tu explicación al usuario. No inventes clientes o flujos de trabajo específicos.
Construye un modelo de problema interno
Úsalo como ayuda para razonar, nunca como texto para publicar:
Alguien en [situación real] está tratando de [tarea], pero [obstáculo]. Quiere [resultado]. El producto ayuda mediante [mecanismo específico].
Luego redúcelo a un momento reconocible. El momento es más importante que una categoría abstracta.
- Abstracto: "Los equipos de finanzas necesitan flujos de trabajo de conciliación optimizados."
- Concreto: "El total de pago y tus registros de transacciones no coinciden."
- Abstracto: "Mejora la observabilidad en implementaciones distribuidas."
- Concreto: "Una implementación falló. Estás buscando en tres servicios para encontrar el error."
Un buen titular puede comenzar con el problema o con el resultado deseado. Elige lo que le diga más rápidamente al visitante previsto: "Esto es para mí." Un titular que comienza con el problema no es automáticamente mejor si la audiencia ya sabe exactamente lo que quiere.
Compón el mensaje
Piensa en estos puntos internamente. No los imprimas como seis secciones idénticas del sitio web.
- Reconocimiento: Una situación real que el visitante ha experimentado o puede imaginar.
- Significado: Lo que sigue sin resolver, difícil, costoso o incierto. Una consecuencia específica suele ser suficiente.
- Alivio: Lo que se vuelve posible o más simple.
- Mecanismo: Cómo el producto lleva al visitante allí.
- Credibilidad: Un ejemplo real, demostración, capacidad, limitación o fuente que genere confianza.
- Próxima acción: Un CTA cuyo destino cumpla su promesa.
La primera pantalla generalmente debe proporcionar reconocimiento, la solución y un mecanismo creíble sin requerir que el visitante se desplace. No dediques media página a dramatizar un problema que el visitante ya entiende.
Escribe el hero
- Titular: Un pensamiento claro sobre la tarea, problema o resultado deseado del visitante. Lo específico supera a lo ingenioso.
- Apoyo: Nombra a quién ayuda y describe cómo funciona en una o dos oraciones naturales. Elimina cualquier palabra que no cambie la comprensión del lector.
- CTA: Una acción real como "Ver un ejemplo", "Leer la documentación", "Probar la demostración" o "Hablar con el mantenedor", solo si esa acción existe.
- Visual: Si hay uno presente o se solicita, prefiere un flujo de trabajo real, estado de la interfaz o ejemplo de datos antes y después, en lugar de metáforas decorativas abstractas.
El titular y el apoyo deben hacer trabajos diferentes. No digas la misma promesa tres veces con palabras diferentes.
Explica la solución como una causa, no un eslogan
Para cada característica importante, razona:
Lo que hace -> qué cambia para el visitante -> por qué eso importa -> qué respalda la afirmación.
Ejemplo:
- Capacidad: Ejecutar SQL generado contra Parquet, JSON y CSV en la infraestructura del cliente.
- Qué cambia: El cliente puede investigar esos archivos sin enviar su contenido a un proveedor de análisis alojado.
- Significado: Sus datos permanecen dentro de la infraestructura que operan.
- Alcance: Esto no demuestra que todo el sistema no tenga riesgos de seguridad.
Usa la parte más relevante de esta cadena en el hero. Coloca el resto en una demostración, sección de flujo de trabajo, FAQ o documentación según sea necesario.
Haz que el texto parezca escrito por una persona
El texto que suena humano a menudo es más específico, menos simétrico y menos ansioso por explicarse a sí mismo. Se siente editado, no generado en una sola pasada.
Favorece
- Una situación concreta en lugar de una etiqueta de categoría.
- Palabras familiares en lugar de jerga conceptual.
- Detalles que solo tengan sentido para esta audiencia y producto.
- Descripciones directas en lugar de emoción vacía.
- Diferentes ritmos de oración cuando ayudan al lector a seguir una idea.
- Un ejemplo útil que aclare la afirmación.
- Límites honestos, compensaciones prácticas y términos técnicos precisos cuando generen confianza.
- Transiciones naturales que sigan la idea real, no frases de conexión prefabricadas.
Elimina o reescribe
- Relleno de marketing: "Desbloquear", "potenciar", "sin interrupciones", "de vanguardia", "innovador", "revolucionario", "capacitar" y términos similares cuando reemplazan significado.
- Contrastes falsos: "No es solo X. Es Y." "Deja de hacer X. Empieza a hacer Y." "El futuro de X está aquí." Solo usa contraste cuando explique una diferencia real, en lenguaje normal.
- Estructura anunciada: "En esta sección, exploraremos..." "Vamos a profundizar." "He aquí por qué esto importa." No le digas a los visitantes que estás a punto de explicar algo; explícalo.
- Reformulación repetitiva: Un titular, subtítulo, tres tarjetas de características y un párrafo final que todos hacen la misma afirmación.
- Secciones perfectamente simétricas: Tres tarjetas con patrones gramaticales idénticos, recuentos de palabras idénticos y un resumen ordenado solo para completar el diseño.
- Significado sobreexplicado: "Esto capacita a las empresas para tomar el control de su éxito." Si la consecuencia es obvia, deja de escribir.
- Lenguaje emocional vacío: "Di adiós a los dolores de cabeza" o "Nunca más te preocupes" sin una razón concreta.
- Trucos conversacionales forzados: Preguntas retóricas repetidas, anécdotas falsas, humor forzado, contracciones excesivas y vulnerabilidad artificial.
- Pulido sintáctico que suena antinatural: Frases nominales densas, cadenas de adjetivos y puntuación haciendo el trabajo de oraciones claras.
No conviertas una lista de palabras prohibidas en tu estrategia de edición. Una palabra puede ser apropiada en el contexto adecuado. El requisito de puntuación anterior es una regla de estilo del proyecto; la tarea más profunda es arreglar el pensamiento, la estructura y la evidencia. Un redactor que simplemente elimina guiones y reemplaza "apalancamiento" con "uso" no ha resuelto el problema.
Edita en dos niveles
Revisión estructural:
- ¿El problema real del lector es visible, o la página está hablando de sí misma?
- ¿Cada sección enseña algo nuevo o elimina una objeción real?
- ¿Aparece el producto antes de que el visitante pierda interés?
- ¿El argumento es lineal solo porque el modelo por defecto usó una plantilla?
- ¿Hay resúmenes innecesarios, etiquetas de etapa repetitivas o narrativas exageradas de antes versus después?
- ¿El contenido sigue cómo decide este visitante en particular, en lugar de un embudo de ventas genérico?
Revisión de oraciones:
- ¿Una persona informada diría realmente esta oración a otra persona?
- ¿Hay un sustantivo o verbo más específico?
- ¿Se puede cortar la oración sin eliminar un hecho?
- ¿La oración intenta sonar impresionante en lugar de explicar algo?
- ¿Son precisos los hechos y apoyables los beneficios?
- ¿Hay guiones largos o cortos en el texto propuesto? Elimínalos.
Lee el resultado como visitante, no como escritor. Si suena a discurso ensayado, simplifica el pensamiento en lugar de agregar más trucos "humanizadores".
Usa la psicología de manera responsable
Usa principios psicológicamente útiles como lentes de diagnóstico, no como excusas para manipular a las personas. Cada principio a continuación es [P].
- Reconocimiento: Las personas se involucran cuando pueden identificar la situación que se describe.
[P] - Facilidad cognitiva: El lenguaje concreto y un camino coherente reducen el esfuerzo.
[P] - Olor de información: Los encabezados y CTA deben predecir con precisión lo que viene a continuación.
[P] - Control: Las personas quieren saber qué pueden inspeccionar, cambiar, conservar o deshacer.
[P] - Confianza: La evidencia, los mecanismos reales y los límites reconocidos pueden ser más útiles que las grandes afirmaciones.
[P] - Motivación: El texto debe conectarse con algo que el visitante quiere lograr, no inventar inseguridad o presión.
[P]
Evita la escasez falsa, las pruebas sociales inventadas, los ahorros de costos inventados, las comparaciones de rendimiento no respaldadas, los valores predeterminados manipuladores o las garantías implícitas.
La arquitectura de la página es situacional
No produzcas la misma página de aterrizaje para un CLI de desarrollador, un producto de operaciones financieras y una utilidad de consumo.
Para audiencias de expertos o desarrolladores: Generalmente, comienza con la tarea práctica o el resultado técnico. Muestra un comando, interfaz, ejemplo, detalle de arquitectura o enlace de documentación temprano. Evita sobreexplicar un problema familiar.
Para compradores operativos: Comienza con un incidente o responsabilidad reconocible. Explica qué pueden investigar, prevenir o completar, luego muestra el flujo de trabajo y las limitaciones.
Para categorías desconocidas: Define el producto temprano, anclalo en una situación conocida y muestra cómo alguien lo usaría realmente. La novedad por sí sola no es una propuesta de valor.
Para una página de una sola característica o ya clara: Haz un cambio preciso. No añadas una historia larga de problemas.
Cada sección debe ganarse su lugar respondiendo una pregunta u objeción real. Si no lo hace, elimínala.
Ejemplo: Queryance
Versión débil, centrada en características
Análisis de código abierto para operaciones financieras. Convierte lenguaje natural en SQL y ejecútalo en archivos Parquet, JSON y CSV en tu infraestructura.
Esto describe primero la maquinaria. Hace que los visitantes deduzcan la razón para importarles.
Versión del problema humano
Descubre por qué tus números de pago no coinciden.
Queryance ayuda a los equipos financieros SaaS a investigar diferencias entre sus registros. Haz una pregunta, revisa el SQL y ejecútalo contra archivos Parquet, JSON o CSV en tu propia infraestructura.
CTA: Habla con el mantenedor
La primera oración nombra un trabajo real. La segunda explica para quién es el producto y cómo funciona. El CTA es apropiado solo si existe una forma de contactar al mantenedor.
Una versión que se esfuerza demasiado
¿Todavía ahogado en el caos financiero?
Deja de perder tiempo en hojas de cálculo obsoletas. Desbloquea una conciliación sin esfuerzo con la próxima generación de operaciones financieras inteligentes.
Esto inventa emociones, se apoya en clichés de la industria y nunca explica el mecanismo. Es más corto que la buena versión pero menos informativo.
Estos ejemplos son puntos de partida, no patrones obligatorios. Si los clientes reales usan un lenguaje diferente, favorece su lenguaje después de verificar lo que significan.
Modos de ejecución
Sigue el alcance de la solicitud del usuario.
Auditoría
Proporciona los 3 a 5 problemas específicos de texto o jerarquía principales. Cita el texto relevante, describe lo que un visitante malinterpretaría o pasaría por alto, y recomienda correcciones específicas. Identifica lo que ya está funcionando. No afirmes mejoras de conversión sin medición.
Reescribe
Proporciona texto listo para producción para las secciones solicitadas, usando la voz de marca existente del sitio.
… [truncado para traducción]