Desarrollo web en Chile

Desarrollo web en Chile: la web como herramienta de venta

Hitos es una agencia de desarrollo web en Chile que construye sitios para empresas que ya venden y necesitan vender más: rápidos, ordenados para Google y para los motores de IA, y diseñados para convertir visitas en contactos o pedidos. No entregamos folletos digitales. Entregamos la pieza donde aterriza el tráfico y donde el negocio gana o pierde.

Esa distinción es todo el encargo. Un folleto informa; una herramienta de venta produce. Por eso el trabajo no termina cuando el sitio se ve bien: termina cuando revisamos que no haya un enlace roto, ni un botón mal puesto y, sobre todo, que no falte un botón donde la persona estaba lista para actuar.

La web tampoco se piensa sola: recibe el tráfico del servicio de SEO y de las campañas de paid media, y entrega cada contacto al sistema de automatización. Si la web falla, todo el gasto anterior se convierte en visitas que rebotan.

Qué hace que una página web convierta más allá del diseño

Una página web convierte cuando el visitante entiende en segundos qué vendes, si le sirve a él y qué tiene que hacer ahora. Todo lo demás es consecuencia: jerarquía visual clara, velocidad, prueba social donde se decide, formularios cortos y un camino sin obstáculos hasta la acción. El diseño ayuda, pero no salva un mensaje confuso.

Después de auditar decenas de sitios, los frenos se repiten con una fidelidad casi aburrida:

• Mensaje genérico en la primera pantalla. Si tu encabezado sirve para cualquier competidor, no está trabajando.
• Demasiados objetivos por página. Una página que pide suscribirse, cotizar, descargar y llamar no pide nada.
• Prueba social escondida. Testimonios y casos sirven donde ocurre la duda, no en una página aparte que nadie visita.
• Formularios que interrogan. Si no vas a usar el dato en 48 horas, no lo pidas todavía.
• Rutas muertas. Páginas sin salida, botones que no llevan a nada, teléfonos que en móvil no se pueden tocar.
• Lentitud. La velocidad no es una categoría aparte de la conversión: es parte de la experiencia.

En nuestros casos de éxito el patrón se repite: el salto grande llega cuando el tráfico crece y, a la vez, la web deja de perder a la gente que ya llegó.

Core Web Vitals explicados para quien no es técnico

Los Core Web Vitals son tres métricas con las que Google mide la experiencia real de tus visitantes: cuánto tarda en aparecer el contenido principal (LCP), qué tan rápido responde la página cuando alguien interactúa (INP) y cuánto se mueve el diseño mientras carga (CLS). Google evalúa el percentil 75 de las visitas reales, y móvil y escritorio se miden por separado.

Traducido a lenguaje humano y a consecuencias de negocio:

El rango que Google marca como “necesita mejorar” va de 2,5 a 4 segundos en LCP, de 200 a 500 milisegundos en INP y de 0,1 a 0,25 en CLS. Por encima de esos techos, la métrica se considera deficiente.

Una advertencia honesta: los Core Web Vitals verdes no te hacen rankear solos. Son un factor de experiencia de página, no un sustituto del contenido ni de la autoridad. Pero funcionan como desempate y, sobre todo, como negocio: aunque Google no existiera, un sitio que responde rápido convierte mejor que uno que hace esperar.

Sitio web rápido: la velocidad se decide en la arquitectura

Un sitio rápido no se logra instalando un plugin de caché al final del proyecto. Se logra decidiendo bien la arquitectura al principio: cuánto código se ejecuta en el navegador, cuántas consultas hace el servidor antes de responder y cuánto pesan las imágenes y las fuentes. La optimización posterior solo maquilla decisiones estructurales.

Este mismo sitio es la prueba del argumento. Está construido con Astro, genera HTML estático y no depende de WordPress: cuando alguien entra, el servidor ya tiene la página lista y no la arma consultando una base de datos y ejecutando plugins. Eso se nota en los tres Core Web Vitals a la vez. Preferimos que nos evalúes midiendo nuestra casa antes que leyendo una promesa.

Rediseño web o reconstruir desde cero: cómo decidir

Conviene rediseñar cuando la base técnica sirve y el problema es de mensaje, estructura o estética. Conviene reconstruir cuando la plataforma limita la velocidad, el CMS acumula deuda técnica, la arquitectura de URLs es un desorden o cada cambio pequeño exige tocar código frágil. La pregunta correcta no es qué tan viejo se ve, sino qué tan caro es cambiarlo.

Aquí viene la advertencia que más caro le sale a las empresas: rediseñar sin plan de migración destruye posicionamiento. Cuando cambian las URLs y nadie mapea las redirecciones 301, Google encuentra cientos de páginas con error, pierde el historial de cada dirección y reparte de nuevo la autoridad que tu sitio tardó años en acumular. La caída suele aparecer a las pocas semanas del lanzamiento, cuando el equipo ya celebró.

Evitarlo no es complejo, pero es meticuloso: inventario de URLs actuales, identificación de las páginas que hoy traen tráfico, mapa uno a uno de redirecciones y monitoreo en Search Console las semanas posteriores al lanzamiento.

Web optimizada para SEO: por qué se diseñan al mismo tiempo

Una web optimizada para SEO se diseña con la estructura de búsqueda ya definida: qué páginas existen, qué intención cubre cada una, cómo se enlazan entre sí y qué jerarquía tienen los encabezados. Cuando eso se decide después de maquetar, el SEO queda condenado a parchar decisiones que ya se tomaron mal.

El síntoma clásico es un sitio precioso con cuatro páginas: home, nosotros, servicios y contacto. Se ve impecable y no tiene dónde rankear, porque no existe una página por cada cosa que la gente busca. Corregirlo después significa crear páginas nuevas, reordenar el menú y rehacer plantillas ya aprobadas: el doble de trabajo.

Por eso, cuando el proyecto web nace dentro de una estrategia de posicionamiento, la arquitectura de información sale del keyword research y no de una intuición de diseño. En rubros con reglas propias, como clínicas y centros médicos, esa estructura contempla además cómo busca el paciente.

Sitio web preparado para la IA: citable, estructurado y legible por máquinas

Un sitio preparado para la IA es aquel que ChatGPT, Perplexity, Gemini y los AI Overviews pueden leer, entender y citar con confianza. Eso exige tres capas: contenido que responde preguntas concretas de forma directa, datos estructurados que definen quién eres y qué ofreces, y una entrega técnica limpia que no obligue al modelo a adivinar.

En la práctica, el contenido se escribe respondiendo primero y desarrollando después: un párrafo que responde en dos líneas es mucho más citable que uno que se calienta durante media página. Los datos estructurados (organización, servicios, productos, preguntas frecuentes y reseñas) le entregan al modelo hechos verificables en lugar de prosa que interpretar. Y el archivo llms.txt, más una política explícita sobre qué rastreadores de IA pueden acceder, ordena qué partes del sitio quieres que los modelos consideren.

Que el sitio se genere como HTML estático ayuda más de lo que parece: varios rastreadores de IA no ejecutan JavaScript con la tolerancia de Google. Si tu contenido solo aparece después de que el navegador ejecuta código, para esos modelos tu página está en blanco. Cuando el objetivo es aparecer en las respuestas generadas, se trabaja de forma dedicada en nuestro servicio de AEO.

WordPress, sitio estático o desarrollo a medida

No existe una plataforma correcta para todos los casos. WordPress sigue siendo la decisión sensata para muchos proyectos, los sitios estáticos ganan cuando la prioridad es velocidad y estabilidad, y el desarrollo a medida se justifica solo cuando el negocio necesita lógica que ninguna plataforma resuelve. Elegir por moda sale caro.

Un ejemplo real: la web institucional de ICOR Research & Innovation Center se construyó en WordPress porque el cliente ya tenía la infraestructura, su equipo publicaba de forma autónoma y el proyecto no exigía nada que WordPress no resolviera bien. Esa era la decisión correcta, no la que nos habría gustado defender técnicamente.

Desarrollo web ecommerce: el precio visible y el resto del embudo

Un ecommerce se juega en tres puntos: que el visitante encuentre el producto, que entienda cuánto cuesta y que el checkout no lo pierda. Todo lo demás, por bonito que sea, es decoración alrededor de esos momentos. La arquitectura de categorías, las fichas y el flujo de pago son el proyecto.

Hay un error donde muchas tiendas se disparan en el pie: esconder el precio. Un visitante que no lo encuentra se va rápido y sin dejar rastro. Uno que sí lo ve, aunque no compre en línea ese día, se lleva el número en la cabeza y empieza a acomodar su presupuesto alrededor de tu producto. Pasa igual con un auto: saber cuánto cuesta el que te gusta es el primer paso para comprarlo algún día. Ocultar el precio no protege el margen, solo te saca de la decisión.

Un proyecto de ecommerce agrega además la configuración de la plataforma, la pasarela de pago (Transbank, MercadoPago o Stripe según el caso), la estructura de catálogo, las reglas de impuestos y envíos, la plantilla de fichas y el tracking de conversiones con píxel y GA4. Los indicadores dejan de ser visitas y pasan a ser conversión de checkout, abandono de carrito e ingreso por sesión.

Cuánto cuesta una página web y de qué depende el presupuesto

El costo de una página web depende del número de plantillas únicas a diseñar, de la cantidad de páginas, de las integraciones necesarias (CRM, pagos, reservas, facturación), del idioma y de si el contenido existe o hay que producirlo. Trabajamos con precio fijo cerrado antes de partir, no con horas abiertas, y el ecommerce parte de una base mayor.

Que el alcance tenga límites declarados por adelantado (rondas de ajustes acotadas, diseño de piezas gráficas cotizado aparte, funcionalidades nuevas fuera del precio base) no es rigidez burocrática: es lo que permite comprometer ese precio y una fecha. Un proyecto con rondas infinitas de cambios no tiene precio ni plazo, tiene una cuenta abierta. Si buscas al proveedor más barato de la plaza, no somos tu agencia.

Cuánto demora un sitio web y qué determina el plazo

Un sitio corporativo toma entre 4 y 8 semanas según su complejidad, y un ecommerce entre 6 y 12 semanas según el tamaño del catálogo y las integraciones. El plazo real casi nunca lo define el desarrollo: lo define la velocidad con que llegan los contenidos y las aprobaciones desde el lado del cliente.

Los proyectos que se estancan lo hacen siempre en el mismo lugar: textos que nadie escribe, fotos que están por llegar, una aprobación que espera a alguien que no participó en el brief. Nada de eso es un problema de código.

Qué necesitamos de tu lado para no perder tiempo

Un proyecto web avanza a la velocidad de las decisiones del cliente. Para cumplir plazo necesitamos cinco cosas concretas, definidas desde el kick off:

1. Un responsable único con poder de decisión. Alguien que consolide los comentarios del equipo y responda con una sola voz. Los comités sin vocero duplican los plazos.
2. Contenidos reales o la decisión de que los produzcamos. Textos, descripciones de producto, biografías y datos de contacto. Si no existen, se decide al principio.
3. Material gráfico utilizable. Logo en vectorial, manual de marca si existe y fotos con resolución suficiente para pantallas grandes.
4. Accesos técnicos. Dominio, hosting, DNS, correo corporativo, analítica y herramientas a integrar. Perseguir claves es la causa número uno de retrasos evitables.
5. Feedback agrupado y en plazo. Comentarios consolidados por ronda. El goteo diario de observaciones rompe cualquier planificación.

Qué preguntar antes de contratar a cualquier desarrollador web

Antes de firmar con una agencia de desarrollo web, pregunta quién queda como titular del dominio, qué te llevas si te vas y cuánto cuesta salir. Esas tres respuestas dicen más que un portafolio completo. Si alguna se responde con vaguedades, ya sabes lo que va a pasar el día que quieras cambiar de proveedor.

• ¿A nombre de quién se registra el dominio? La respuesta correcta es siempre a nombre del cliente. En Hitos permanece a tu nombre desde el primer día.
• ¿Me entregan archivos fuente, base de datos y accesos si termino la relación? Nosotros los entregamos sin retención y sin costo de salida.
• ¿El hosting es mío o del proveedor? El nuestro va incluido los primeros meses y después decides: te lo llevas o te quedas con el plan de mantención.
• ¿La licencia del tema o template es transferible? Muchos sitios propios viven sobre licencias que pertenecen a la agencia.
• ¿Qué pasa con mi posicionamiento durante la migración? Si no mencionan redirecciones 301, cambia de proveedor.
• ¿Qué está fuera del alcance? Quien no sabe decir que no, todavía no calculó su propio plazo.

Mantención de sitios web: un servicio, no un favor

La mantención web cubre monitoreo de disponibilidad, certificado SSL vigente, respaldos periódicos, actualizaciones de seguridad del CMS, mejoras de velocidad y ajustes de contenido con horas dedicadas. Es un servicio mensual recurrente con alcance propio, no una cortesía indefinida que se pide por WhatsApp cuando algo se rompe.

Lo planteamos así por una razón práctica: un sitio sin mantención se degrada en silencio. Los plugins quedan desactualizados y abren vulnerabilidades, los certificados vencen, los formularios dejan de enviar correos sin avisar y la velocidad se erosiona con cada imagen pesada. Nadie lo nota hasta que el sitio cae, y entonces el costo ya no es mensual: es una emergencia.

Se mide con indicadores verificables: disponibilidad sobre 99,5%, score de PageSpeed, vulnerabilidades resueltas, horas usadas frente a disponibles y tickets cerrados en el mes. Es opcional: si prefieres administrar el sitio con tu equipo, te entregamos todo lo necesario para hacerlo.

Preguntas frecuentes sobre desarrollo web

¿Pierdo mi posicionamiento en Google si cambio de sitio web?

No, si la migración se planifica. El riesgo no está en cambiar de sitio, sino en cambiar las URLs sin mapear redirecciones 301 desde cada dirección antigua a su equivalente. Cuando ese mapa existe y se conservan los contenidos que rankean, el traspaso de autoridad ocurre en semanas. Cuando no existe, la caída puede tardar meses en revertirse.

¿Quién escribe los textos del sitio web?

Podemos escribirlos nosotros o partir de los tuyos. Lo importante es definirlo en el brief inicial, porque es la variable que más mueve el plazo. Si el contenido lo produce tu equipo, necesitamos fechas comprometidas; si lo producimos nosotros, entra al alcance antes de comenzar el diseño, no después de aprobarlo.

¿Puedo editar el sitio yo mismo después del lanzamiento?

Sí, y el proyecto incluye la capacitación para hacerlo. Las secciones que cambian seguido (textos, imágenes, noticias, productos) quedan editables sin tocar código. Lo que conviene no mover sin apoyo son las plantillas y la estructura de URLs, porque ahí un cambio pequeño puede costar posicionamiento.

¿Sirve una landing page o necesito un sitio completo?

Depende del objetivo. Una landing page que convierte es la herramienta correcta cuando tienes una campaña con un mensaje único y quieres medir conversión sin distracciones. Un sitio completo es necesario cuando buscas posicionamiento orgánico, porque el SEO requiere una página por cada intención de búsqueda que quieras cubrir.

¿Cómo sé si el sitio nuevo está funcionando?

Con datos definidos antes de lanzar. Dejamos configurados GA4 y Search Console, con los formularios y las acciones importantes marcados como conversión, para comparar contra el sitio anterior. Lo que importa es tasa de conversión, contactos generados y páginas indexadas, no la cantidad de cumplidos que recibe el diseño.

¿Trabajan con empresas que ya tienen equipo de marketing interno?

Sí, y suele funcionar muy bien. Entramos como el equipo que construye y ordena la plataforma, mientras el equipo interno mantiene la marca y la operación diaria. Lo que sí pedimos es claridad sobre quién decide y quién aprueba: un proyecto con dos capitanes avanza a la mitad de la velocidad.

¿Tu web está frenando el resto de tu marketing? Agenda una reunión y revisemos qué conviene en tu caso: ajustar lo que tienes o construir algo que convierta.