SEO técnico para apps web: que Google te encuentre

Tenés una aplicación web que funciona perfecto, pero cuando buscás tu marca en Google aparece a duras penas, y por las keywords que importan no aparecés nunca. La causa más frecuente de que una aplicación web no rankee es que está construida como una SPA (Single Page Application) que arma el contenido con JavaScript en el navegador. Google a menudo ve una página vacía o tarda demasiado en renderizar, y no indexa lo que no puede leer rápido. La solución es servir HTML ya renderizado con SSR o SSG. Acá va el SEO técnico que separa una app invisible de una que captura tráfico orgánico.

Por qué tu SPA no aparece en Google

Una SPA carga un HTML casi vacío y después JavaScript "pinta" el contenido en el navegador. Para un usuario es instantáneo y fluido. Para Google, es un problema: su crawler tiene que descargar, encolar y ejecutar ese JavaScript en una segunda pasada que puede demorar días o semanas, y muchas veces no llega a ver el contenido completo.

El resultado es el clásico soft 404: Google ve una página que técnicamente carga, pero sin contenido real, y decide no indexarla o indexarla como página de baja calidad. Si tu app pública depende de tráfico orgánico, esto es fatal.

SSR y SSG: la diferencia que hace que te encuentren

La solución es entregarle a Google el HTML ya armado. Hay dos formas:

• SSR (Server-Side Rendering): el servidor genera el HTML en cada visita. Ideal para contenido dinámico o personalizado.
• SSG (Static Site Generation): el HTML se genera una sola vez, en el build. Ideal para contenido que no cambia seguido: blog, landings, páginas de servicio.

Estrategia	Qué ve Google	Velocidad	Cuándo usarla
SPA pura (CSR)	HTML vacío, JS pendiente	Buena tras cargar	Apps privadas tras login
SSR	HTML completo por visita	Buena	Contenido dinámico público
SSG	HTML completo pre-armado	Excelente	Blog, landings, catálogos
Híbrido (SSG + ISR)	HTML completo, se revalida	Excelente	El estándar 2026

En 2026, el enfoque que recomendamos para la mayoría de las apps con páginas públicas es un framework como Next.js que combina SSG para lo estático con SSR/ISR para lo dinámico. Lo cubrimos a fondo en React o Next.js para tu proyecto.

Una variante intermedia es el pre-renderizado en build (prerendering): herramientas que recorren tu SPA y guardan una versión HTML estática de cada ruta. Funciona como parche cuando ya tenés una SPA armada y no querés reescribirla, pero es frágil: si una ruta no entra en la lista de páginas a pre-renderizar, Google la ve vacía. Por eso, en proyectos nuevos, conviene partir de un framework con SSR/SSG nativo en vez de parchear después.

¿Tu app web no aparece en Google y no sabés por qué? Agendá un diagnóstico de 30 minutos y te decimos exactamente qué está bloqueando tu indexación.

Core Web Vitals: la velocidad como factor de ranking

Google no solo mira el contenido; mide la experiencia real con los Core Web Vitals:

• LCP (Largest Contentful Paint): cuánto tarda en cargar el contenido principal. Objetivo: menos de 2,5 segundos.
• INP (Interaction to Next Paint): cuán rápido responde tu app a clics y toques. Objetivo: menos de 200 ms.
• CLS (Cumulative Layout Shift): cuánto "salta" el contenido mientras carga. Objetivo: menos de 0,1.

Una app que tarda 6 segundos en pintar el contenido en móvil pierde dos veces: el usuario se va y Google la rankea peor. Si querés profundizar en esto, lo desarrollamos en performance web y velocidad.

Checklist de SEO técnico para tu app web

Lo que revisamos en cada auditoría:

Indexabilidad

1. HTML renderizado: cada página pública sirve contenido en el HTML inicial, no solo tras ejecutar JS.
2. robots.txt correcto: no bloquees por accidente lo que querés indexar.
3. Sitemap.xml generado y enviado a Search Console.
4. Canonical tags para evitar contenido duplicado.

Metadatos

5. Title y meta description únicos por página, con la keyword al inicio.
6. Open Graph para que se vea bien al compartir.
7. Datos estructurados (JSON-LD): Schema de Organización, FAQ, Breadcrumb. Esto también ayuda a que los LLM te citen.

Arquitectura

8. URLs limpias y semánticas: /servicios/desarrollo-web y no /page?id=42.
9. hreflang si tenés versiones en varios idiomas.
10. Enlazado interno coherente entre páginas relacionadas.

Rendimiento

11. LCP < 2,5s en móvil real (no solo en tu fibra).
12. Imágenes optimizadas en formato moderno y con lazy loading.
13. JavaScript dividido (code splitting) para no enviar todo de golpe.

Errores de SEO técnico que vemos seguido

Más allá del problema de fondo de la SPA, en las auditorías aparecen siempre los mismos descuidos que sabotean la indexación:

• Bloquear recursos en robots.txt: por intentar "ocultar" carpetas, terminan bloqueando el JavaScript o el CSS que Google necesita para renderizar.
• Contenido detrás de interacción: información clave que solo aparece tras hacer clic en una pestaña o un acordeón. Google no hace clic; si no está en el HTML, no lo indexa.
• Paginación o filtros que generan URLs infinitas: catálogos con combinaciones de filtros crean miles de URLs casi iguales que diluyen el presupuesto de rastreo (crawl budget).
• Mismos title y description en todas las páginas: copiar el metadato genérico en toda la app hace que Google las trate como duplicadas.
• No tener versión HTML del contenido dinámico: listados de productos o artículos que se cargan solo por API quedan invisibles si no hay SSR.

Ninguno requiere rehacer la app: son ajustes puntuales, pero su efecto sumado es enorme. Una app con buen contenido y estos errores corregidos puede pasar de cero a cientos de páginas indexadas en pocas semanas.

Cuándo el SEO técnico NO es tu prioridad

Seamos honestos: no toda aplicación necesita SEO técnico.

• Si tu app es una herramienta interna o un panel tras login, no necesitás que Google la indexe. Ahí importa la velocidad para el usuario, no el ranking. Es el caso de un software a medida de uso interno.
• Si tu producto crece por ventas directas o publicidad paga, el orgánico es secundario y conviene invertir primero en conversión.
• Si todavía no validaste el producto, optimizar SEO es prematuro: primero confirmá que la idea funciona.

El SEO técnico rinde cuando tu modelo depende de que gente nueva te descubra buscando una solución que vos ofrecés.

GEO: que los LLM también te citen

Hay una capa nueva en 2026 que se apoya en lo mismo. Cada vez más gente busca a través de asistentes de IA como ChatGPT, Claude o Perplexity en vez de Google directo. Estos modelos leen el HTML de tu página igual que un crawler, y citan fuentes que entienden con claridad.

La buena noticia: lo que optimiza para LLM es casi lo mismo que optimiza para Google. HTML renderizado, contenido estructurado con encabezados claros, respuestas directas y autocontenidas a preguntas concretas, y datos estructurados (Schema FAQ, Organización). Una app construida con buen SEO técnico ya está mitad del camino hecho para ser citada por IA. Una SPA que ni Google puede leer, tampoco la lee un LLM.

De tráfico a leads: el paso que falta

Aparecer en Google no sirve de nada si el visitante rebota. El SEO técnico trae la visita; la arquitectura de la página la convierte. Por eso lo tratamos junto: páginas rápidas, indexables y diseñadas para que el lector dé el siguiente paso.

En Deepyze construimos aplicaciones web y sitios con SSR/SSG desde el diseño, no parcheados después. Auditamos tu app actual, identificamos qué bloquea tu indexación y lo resolvemos con precio fijo y un equipo en tu huso horario. Contanos tu caso y en 24 horas tenés una propuesta con diagnóstico y plan concreto.