Todo lo que hacemos para construir sitios de marketing y productos rapidos, medibles, listos para SEO y accesibles, escrito en su totalidad. Como definimos el alcance, como elegimos el stack, como aplicamos los presupuestos de rendimiento, como se integra la analitica desde el primer dia y como transcurre el encargo del audit al lanzamiento. Sin contenido de relleno, sin secretos guardados.
Esta guia es larga porque las decisiones que determinan si un sitio rinde, se posiciona y convierte se toman pronto, antes de que se escriba ninguna linea de codigo. La mayoria de ellas tambien son invisibles para quienes pagan por el proyecto, y asi es como se acaba con un sitio precioso que obtiene 38 en Lighthouse y no tiene ningun seguimiento de analitica sobre lo que ocurre despues de que alguien haga clic en la CTA del hero. Lo que sigue es como pensamos en cada una de esas decisiones, en el orden en que las tomamos.
Definir el alcance es un ejercicio diagnostico, no comercial. El resultado de un buen proceso de scoping es un documento lo bastante preciso para que quienes realizan el trabajo no puedan malinterpretar que esta incluido y que no, y lo bastante claro para que quienes pagan sepan exactamente lo que tendran al final de cada sprint. Cualquier cosa vaga en un alcance es una futura disputa esperando ocurrir.
Definimos el alcance en tres pasadas. La primera es la auditoria tecnica gratuita: que existe ahora, que esta mal y cuales son las limitaciones. La segunda es un brief escrito que cubre los entregables, los criterios de aceptacion para cada uno, los presupuestos de rendimiento objetivo, los eventos de analitica que se seguiran y los criterios de lanzamiento. La tercera es el plan de sprints: el trabajo dividido en ventanas de dos semanas, cada una terminando en algo que puedes probar y aprobar.
La estimacion sigue naturalmente del brief. Si el brief es preciso, la estimacion es precisa. Si no lo es, no adivinamos; hacemos las preguntas que lo hacen preciso antes de que cambie ningun dinero de mano. Asi se evita el patron clasico en que un proyecto a precio fijo se convierte en una serie de ordenes de cambio porque el alcance original era un parrafo de copy comercial.
Que contiene un documento de alcance. Entregables por tipo de pagina y componente, criterios de aceptacion por entregable, presupuestos de rendimiento (objetivos LCP, CLS, INP), eventos de analitica y destinos, integraciones de terceros, soporte de navegador y dispositivo, estandar de accesibilidad (WCAG 2.1 AA por defecto), entorno de despliegue y documentacion de traspaso. Si no esta en el alcance, no esta en el precio.
Las estimaciones se dan en rangos de tiempo, no en numeros unicos. Damos un caso optimo y un caso realista, explicamos que determina la diferencia y construimos el plan de sprints desde el caso realista. Inflar un proyecto con buffer artificial no es honesto; decirte que un proyecto de cinco semanas llevara tres tampoco es util.
Cada encargo comienza con una auditoria tecnica de lo que ya tienes, porque lo mas caro en el desarrollo web es construir en la direccion equivocada. La auditoria responde a dos preguntas antes de que se escriba ningun alcance: que esta realmente mal en el sitio o proyecto actual, y cuanto valdria corregirlo?
La auditoria cubre cinco capas:
El resultado es un informe escrito con cada hallazgo categorizado por impacto (critico, alto, medio, bajo), la URL o componente especifico donde ocurre y la correccion. Lo revisamos en una breve llamada y te quedas con el informe independientemente de si nos contratas.
La eleccion del stack es un ejercicio de correspondencia con las limitaciones. El stack adecuado es el que encaja con el modelo de contenido, las habilidades del equipo, los requisitos de rendimiento y la trayectoria de crecimiento. No es el framework mas nuevo, ni el que mas le gusta al desarrollador principal, ni el que produce la demo mas impresionante.
La decision principal es si el sitio es estatico, server-rendered o una aplicacion client-side completa, y si hay un CMS implicado. Aqui esta el desglose practico:
| Enfoque | Ideal para | Compensaciones |
|---|---|---|
| Sitio estatico (HTML, CSS, JS minimo) | Landing pages, sitios de marketing con pocos cambios, documentacion | Carga mas rapida posible, hosting mas sencillo; no apto para contenido dinamico o funcionalidades autenticadas |
| Static site generator (Eleventy, Hugo, Astro) | Sitios con mucho contenido y actualizaciones poco frecuentes, blogs, knowledge hubs | Excelente rendimiento base, se combina bien con headless CMS; el tiempo de build crece con el volumen de contenido |
| Framework server-rendered (Next.js, Nuxt, SvelteKit) | Sitios de marketing con personalizacion, paginas de producto, e-commerce | SEO solido por defecto, estrategias de renderizado flexibles; mas infraestructura que gestionar |
| Headless CMS con frontend | Sitios donde equipos no tecnicos publican contenido con frecuencia | Mejor separacion de responsabilidades; anade una dependencia y un coste mensual por la plataforma CMS |
| Producto completo (SPA o app server-rendered) | Funcionalidades de producto autenticadas, dashboards, herramientas con estado | Maxima flexibilidad; mayor complejidad, build mas largo, requiere tratamiento SEO cuidadoso para las paginas publicas |
La eleccion entre un static site generator y un framework server-rendered es la que los equipos se equivocan con mas frecuencia. Si el sitio es principalmente contenido de marketing con actualizaciones poco frecuentes y sin personalizacion, un generador estatico superara siempre a un framework server-rendered y costara mucho menos en hosting y mantenimiento. Recomendamos un framework cuando el contenido es dinamico, el equipo necesita renderizado por usuario o el sitio necesita crecer hacia funcionalidades de producto con el tiempo.
Hacemos esta recomendacion por escrito como parte del alcance, con el razonamiento y las compensaciones, de modo que la decision sea explicita y documentada. No promovemos un stack concreto porque sea el que mejor conocemos; promovemos el que encaja con el problema.
Un presupuesto de rendimiento es un conjunto de restricciones acordadas por escrito antes de que se commitee la primera linea de codigo. Sin uno, el rendimiento siempre se sacrifica a favor de las funcionalidades porque el coste de anadir un script de terceros o una imagen no optimizada es invisible hasta que alguien ejecuta Lighthouse y encuentra una puntuacion de 42.
Trabajamos con tres umbrales Core Web Vitals de Google:
fetchpriority="high". Corregir la imagen hero sola mueve a la mayoria de sitios del fallo a superar LCP.Aplicacion del presupuesto de rendimiento. Establecemos umbrales de Lighthouse CI en el pipeline de despliegue para que cualquier commit que empeore una puntuacion de Core Web Vitals bloquee el despliegue hasta que se corrija. Esto previene la degradacion lenta que convierte un sitio rapido en uno lento durante doce meses de incorporacion de funcionalidades.
Mas alla de los tres Core Web Vitals, presupuestamos el peso total de la pagina, el tamano del bundle JavaScript, el numero de recursos que bloquean el renderizado y el numero de scripts de terceros permitidos en las paginas criticas para el rendimiento. Cada uno se escribe en el alcance para que todos los que trabajan en el proyecto conozcan la restriccion antes de proponer algo que la romperia.
Los scripts de terceros merecen atencion especial. La analitica, los widgets de chat, las herramientas de A/B testing y los pixels de marketing son individualmente pequenos; colectivamente anadien habitualmente de dos a cuatro segundos al tiempo de carga e introducen layout shifts. Usamos un patron de fachada para las herramientas no criticas: cargamos un marcador de posicion ligero que solo carga el script completo cuando el usuario interactua con el. El widget de chat se carga cuando el usuario hace clic en el boton de chat, no al cargar la pagina.
Un build listo para SEO no es una lista de verificacion que se aplica al final. Es un conjunto de decisiones estructurales tomadas antes de que se escriba ningun contenido. El mayor error que cometen los equipos es construir un sitio, lanzarlo y luego pedir a un consultor SEO que solucione los problemas, momento en el que arreglarlos implica rehacer la arquitectura subyacente en lugar de anadir un meta tag.
Cada pagina necesita un unico H1, una jerarquia de encabezados logica (H2 para secciones, H3 para subsecciones), elementos landmark para navegacion, contenido principal y footer, y texto alternativo descriptivo en cada imagen. Estas son las cosas de las que dependen tanto Googlebot como los lectores de pantalla para entender la pagina, y no cuestan nada hacerlas bien la primera vez.
Googlebot puede renderizar JavaScript, pero lo hace en una segunda oleada que puede tardar dias para paginas que aun no son autoritativas. Para las paginas publicas que necesitan posicionarse, el server-side rendering o la generacion estatica es mas seguro que una aplicacion solo client-side. Si tu producto es una single-page application, las paginas de marketing y landing pages deberian renderizarse estaticamente aunque el producto autenticado no lo sea.
Incluimos datos estructurados en cada tipo de pagina desde el primer dia, usando los tipos que corresponden al contenido. El despliegue sigue un mapa estandar:
| Tipo de schema | Donde va | Que desbloquea |
|---|---|---|
| Organization | En todo el sitio (normalmente en el footer o head) | Panel de conocimiento de marca, logo en los resultados de busqueda |
| BreadcrumbList | Cada pagina con una jerarquia de navegacion | Ruta de breadcrumb en el resultado de busqueda |
| WebSite con SearchAction | Homepage | Caja de busqueda de sitelinks en consultas de marca |
| FAQPage | Paginas con una seccion FAQ genuina | Acordeon FAQ expandible en el resultado |
| Article | Posts de blog y guias | Fecha de publicacion, autor e indexacion mejorada |
| Product | Paginas de producto o precios donde aplique | Precio y disponibilidad en el resultado |
| SoftwareApplication | Paginas de producto SaaS | Datos de valoracion y plataforma en el resultado |
Cada bloque de datos estructurados se valida con el Rich Results Test de Google antes del lanzamiento y se monitoriza en Search Console despues. Un schema no valido es peor que ninguno: produce una advertencia de accion manual si Google lo encuentra engasoso.
Cada pagina necesita un tag canonical autorreferencial que apunte a su URL preferida. Si el sitio tiene versiones en varios idiomas o locales, cada pagina necesita un conjunto completo de anotaciones hreflang, incluyendo un hreflang autorreferencial y un x-default. El hreflang ausente o incorrecto es uno de los errores mas comunes y costosos en sitios internacionales: Google a menudo indexa la version en el idioma equivocado para cada mercado, lo que divide las senales de ranking y diluye la autoridad entre versiones.
Los titulos se mantienen por debajo de 60 caracteres. Las meta descripciones por debajo de 155. Ambos se escriben antes del lanzamiento, no se generan automaticamente de la primera frase del cuerpo del texto. Son lo primero que ve un buscador en el resultado y determinan si alguien hace clic, independientemente de la posicion de ranking.
La accesibilidad no es un ejercicio de cumplimiento. Es un estandar de calidad del build. Un sitio inaccesible para usuarios de teclado tiene la navegacion rota para usuarios avanzados. Un sitio con bajo contraste de color falla bajo la luz del sol, no solo para usuarios con discapacidades visuales. Un sitio sin etiquetas ARIA adecuadas es mas dificil de analizar para Google, no solo para usuarios de lectores de pantalla.
Trabajamos con WCAG 2.1 AA en cada build. Las practicas que mas importan en un sitio de marketing tipico o proyecto de producto digital:
Los tests automatizados detectan aproximadamente el 30-40% de las violaciones WCAG. El resto requiere tests manuales. Ejecutamos escaneos automatizados en cada commit usando axe-core y hacemos una comprobacion manual de teclado y lector de pantalla en cada tipo de pagina antes del lanzamiento.
La analitica es casi siempre una ocurrencia tardia en los proyectos web. El sitio se lanza, alguien anade Google Analytics a traves de un plugin CMS y tres meses despues el negocio no tiene idea de lo que realmente esta impulsando las conversiones porque los eventos nunca se configuraron para responder a las preguntas que importan.
Configuramos la analitica antes de que termine el primer sprint, con los eventos mapeados a las preguntas de negocio, no a lo que es facil de rastrear. La configuracion sigue un brief escrito durante el scoping:
Sobre medicion y privacidad. Implementamos la analitica en conformidad con los requisitos GDPR y ePrivacy: gestion de consentimiento antes de que se active cualquier rastreo, IP anonimizada por defecto, configuracion de retencion de datos revisada en el lanzamiento y sin informacion de identificacion personal en los parametros de eventos. Hacerlo bien desde el inicio es mucho mas economico que adaptar una capa de consentimiento conforme en un sitio que ha estado rastreando todo durante doce meses.
Despues del lanzamiento, realizamos un QA pass del rastreo: cada evento se activa en el desencadenante correcto, sin eventos duplicados, sin eventos ausentes y los datos en la plataforma de analitica coinciden con el comportamiento esperado del usuario. Lleva medio dia y evita meses de trabajo basado en datos incorrectos.
Un sistema de componentes es la diferencia entre un sitio que mantiene la coherencia mientras crece y uno que desarrolla doce estilos de boton ligeramente diferentes en diecisiete paginas porque cada una se construyo de forma independiente. Es tambien la diferencia entre un sitio donde un equipo no tecnico puede publicar nuevo contenido de forma segura y uno donde cada nueva pagina requiere que un ingeniero copie y pegue el markup esperando no romper nada.
Construimos cada sitio con una biblioteca de componentes documentada. El alcance cubre que componentes se necesitan y cuantas variantes requiere cada uno. La implementacion cubre tres aspectos:
Para sitios de marketing, construimos el sistema de componentes en el framework especificado en el alcance, o en HTML y CSS plano para sitios estaticos. Para productos digitales, adoptamos por defecto un patron de componentes headless donde la capa visual esta separada de la logica de negocio, de modo que el sistema de diseno puede actualizarse sin tocar el codigo de la aplicacion.
La eleccion del CMS es una decision de flujo de trabajo, no tecnologica. El CMS correcto es el que permite a las personas que realmente actualizaran el sitio hacerlo sin abrir un ticket, romper el layout o necesitar entender el codebase.
Las principales opciones con las que trabajamos y cuando recomendamos cada una:
Las migraciones de CMS merecen atencion separada. Mover contenido de una plataforma a otra es casi siempre mas complicado de lo que parece: redirecciones para URLs que cambian, contenido que no se mapea bien al nuevo schema, imagenes que necesitan subirse de nuevo y metadatos SEO que necesitan preservarse. Planificamos las migraciones en el alcance, construimos los scripts de importacion antes de tocar el sitio en vivo y verificamos cada redireccion antes del dia del lanzamiento.
Un sitio de marketing o producto moderno tipicamente se conecta a cinco o quince servicios externos en el lanzamiento: analitica, CRM, email marketing, soporte al cliente, procesamiento de pagos, gestion de formularios y lo que el propio producto necesite. Cada integracion es un posible punto de fallo, un riesgo de rendimiento y una superficie de privacidad. Las tratamos con el mismo rigor que el codigo de la aplicacion.
La lista de verificacion de integracion que seguimos antes de anadir cualquier servicio de terceros:
La gestion de formularios es un area comun donde las cosas van mal. Usamos un handler del lado del servidor o un servicio de formularios (Formsubmit, Netlify Forms o una funcion serverless) en lugar de exponer una direccion de email o una clave API de email transaccional en el cliente. Los campos honeypot, el rate limiting y reCAPTCHA son estandar; la eleccion entre ellos depende del volumen de envios y la sensibilidad de los datos.
Para productos digitales con su propia API, escribimos un contrato API antes de que se escriba cualquier codigo frontend o backend. El contrato cubre endpoints, estructuras de request y response, autenticacion, codigos de error y paginacion. El desarrollo frontend y backend puede entonces proceder en paralelo contra el contrato acordado, en lugar de secuencialmente, que es como se mantiene alta la velocidad de los sprints en un producto digital.
La seguridad en un sitio de marketing o producto digital no es glamurosa, pero las bases son innegociables. Los errores que causan las brechas son casi siempre los obvios: secretos expuestos en codigo client-side, sin Content Security Policy, dependencias con vulnerabilidades conocidas y sin aplicacion de HTTPS.
La lista de verificacion de seguridad que ejecutamos antes del lanzamiento en cada encargo:
El hosting es donde el rendimiento, la fiabilidad y la seguridad se unen. La eleccion del hosting debe seguir a la eleccion del stack: un sitio estatico no necesita un servidor; una aplicacion server-rendered si. Elegir el hosting equivocado para el stack lleva a complejidad y costes innecesarios.
Para sitios estaticos y sitios construidos con static site generators, adoptamos por defecto un host CDN-first (Netlify, Vercel o Cloudflare Pages). Cada pagina se sirve como un archivo pre-construido desde una ubicacion edge cercana al visitante, sin round-trip al servidor para el HTML inicial. Los tiempos de carga que tardarian dos a tres segundos desde un servidor de una sola region caen por debajo del medio segundo desde un CDN edge. La diferencia de coste entre un host CDN y un servidor es a menudo cero para los volumenes de trafico que manejan startups y scaleups.
Para aplicaciones server-rendered y productos digitales, evaluamos los requisitos de infraestructura frente al trafico esperado y el presupuesto. Un producto pequeno con unos pocos miles de usuarios al mes no necesita un cluster de Kubernetes; necesita un VPS bien configurado o una plataforma gestionada como Railway o Render con configuraciones de autoescalado razonables.
Cada pipeline de despliegue que configuramos incluye entornos de vista previa: despliegues aislados y accesibles publicamente de cada pull request o rama, con una URL unica generada automaticamente. Los entornos de vista previa permiten a todo el equipo (disenadores, redactores, QA, fundadores) revisar y aprobar los cambios antes de que se fusionen al main. Tambien permiten detectar regresiones antes de que lleguen al sitio en vivo, porque la vista previa ejecuta el mismo build que produccion.
El pipeline de despliegue se ejecuta en cada commit a la rama main: build, lint, unit tests, comprobacion de Lighthouse CI contra los presupuestos de rendimiento y despliegue. Si alguna etapa falla, el despliegue se bloquea. No es opcional; es como se previene la acumulacion lenta de deuda tecnica que convierte un sitio con buen rendimiento en uno lento.
El build que se entrega en el lanzamiento no es el que funciona en dos anos. Escalar un sitio o producto tiene que ver principalmente con las decisiones tomadas pronto: un sistema de componentes que facilita anadir paginas de forma coherente, un CMS que permite a los equipos no tecnicos publicar sin soporte de ingenieria, una lista de dependencias que no crece sin gobernanza y un codebase que los nuevos ingenieros pueden navegar sin una orientacion de tres dias.
Las practicas que mas afectan a la mantenibilidad a largo plazo:
El coste real de la deuda tecnica en un proyecto web no es el codigo que necesita ser reemplazado. Es el tiempo que se dedica a trabajar alrededor de codigo que nadie entiende pero todos temen tocar. El mejor momento para prevenirlo es durante el build inicial. El segundo mejor momento es un sprint dedicado a la deuda tecnica, que podemos definir por separado si el codebase ya la ha acumulado.
Cada encargo sigue la misma estructura: auditoria, alcance, build en sprints, lanzamiento y traspaso. La estructura es la misma tanto si estamos construyendo una landing page como un producto completo; el tamano de cada fase escala con el alcance.
Las fases en orden:
Como gestionamos trabajo de crecimiento y SEO para las mismas empresas para las que construimos, el traspaso puede transicionar a un encargo continuado o quedarse como un proyecto puntual. Ambas opciones estan bien. El sitio que construimos es tuyo, el codigo es tuyo y la documentacion esta escrita para que puedas gestionarlo de forma independiente.
Cuanto tiempo lleva un proyecto tipico? Una landing page suele llevar de cuatro a seis semanas desde la firma del alcance hasta el lanzamiento, incluyendo contenido, QA y despliegue. Un sitio de marketing completo lleva de ocho a doce semanas. Un producto digital depende del alcance pero lo estructuramos en sprints fijos de dos semanas para que veas software funcional al final de cada uno.
Trabajais con el stack existente? Si, si la auditoria nos dice que el stack actual es solido. Recomendamos un cambio solo cuando el actual es una limitacion real para lo que necesitas hacer, y explicamos el razonamiento antes de que comience cualquier trabajo.
Cuanto cuesta? La auditoria es gratuita. El proyecto se define despues de la auditoria porque el alcance correcto depende de lo que encontremos y de lo que quieras lanzar. Escribimos el alcance y el precio en el acuerdo antes de que comience cualquier trabajo.
Podeis gestionar SEO y crecimiento despues del proyecto? Si. Gestionamos SEO, contenido y link building para las mismas empresas para las que construimos sitios. El build que entregamos ya esta listo para SEO; el trabajo de crecimiento se construye sobre el. No hay traspaso a otra agencia.
Y si necesitamos cambios despues de que el alcance este definido? Los cambios fuera del alcance acordado se definen como un elemento separado con un precio separado, antes de que comience cualquier trabajo en ellos. No absorbemos cambios fuera del alcance en silencio para luego facturarlos al final.
Ese es el metodo completo. Cuando quieras aplicarlo a tu sitio o a tu proximo proyecto, el siguiente paso es una auditoria gratuita: resultados reales sobre tus datos reales de Lighthouse y de campo, en aproximadamente una semana, sin ningun compromiso.
Una auditoria tecnica gratuita de tu sitio o proyecto. Resultados reales sobre tus datos reales de Lighthouse y de campo. Un alcance fijo para arreglar lo que importa. Resultados en una semana.
Solicita una auditoria gratuita