Recuerdo perfectamente la primera vez que usé Gmail, allá por sus inicios. La sensación de archivar un correo y que la página no se recargara entera fue… mágica. Parecía brujería. Esa «brujería» tiene un nombre, y es la razón por la que hoy navegamos por webs fluidas y dinámicas: se llama AJAX. Llevo más de una década metido en el barro del SEO y el desarrollo web, y te aseguro que entender AJAX no es solo cosa de programadores. Si tienes una web, si te preocupa la experiencia de usuario y, sobre todo, si quieres que Google te quiera, necesitas saber de qué va esto.
En este artículo te voy a desmontar AJAX pieza por pieza. Olvídate de definiciones académicas infumables. Te explicaré qué es de verdad, cómo funciona con un ejemplo que hasta mi abuela entendería, si sigue siendo relevante en la actualidad y, lo más importante para nosotros, cómo puede ser tu mejor amigo o tu peor enemigo para el SEO. Vamos al lío.
¿Qué es AJAX exactamente? Desmontando el mito
Lo primero y más importante, que es un error que veo constantemente: AJAX no es un lenguaje de programación. No es una tecnología, ni un framework. Te lo digo claro: AJAX es una técnica, un conjunto de tecnologías que ya existían y que se combinaron de una forma inteligente para conseguir algo brutal: que una página web pueda comunicarse con el servidor en segundo plano, sin necesidad de recargarse por completo.
El término lo acuñó Jesse James Garrett en 2005 y significa Asynchronous JavaScript and XML. Aunque el nombre se ha quedado un poco anticuado (ahora se usa más JSON que XML), la idea de base sigue siendo la misma y revolucionó por completo la forma en que interactuamos con las aplicaciones web.
No es un lenguaje, es un concepto
Piénsalo así: antes de AJAX, cada vez que hacías clic en algo (un botón, un enlace), tu navegador le pedía la página entera de nuevo al servidor. Era como pedir un libro completo cada vez que solo querías leer una frase. Un desperdicio de tiempo y recursos. AJAX es como tener un camarero discreto que va a la cocina (el servidor) a por un dato concreto (el precio de un producto, un nuevo comentario) y te lo trae a la mesa sin interrumpir la conversación. La página principal no se inmuta, solo se actualiza esa pequeña parte.
Los 4 pilares tecnológicos de AJAX
Para que esta magia funcione, AJAX se apoya en varias tecnologías que trabajan juntas. Las principales son:
- HTML y CSS: Para la estructura y presentación de la información. La base de cualquier web.
- DOM (Document Object Model): Es la forma en que JavaScript ve y manipula el contenido de la página. AJAX lo usa para actualizar partes específicas del HTML sin recargar.
- JavaScript: El cerebro de la operación. Es el lenguaje que orquesta todo el proceso, iniciando la petición y manejando la respuesta.
- XMLHttpRequest (XHR): Este es el objeto clave. Es el «mensajero» que JavaScript envía al servidor para pedirle datos de forma asíncrona. Aunque hoy en día tiene competidores como la Fetch API, XHR fue el origen de todo.
- JSON o XML: El formato en que se transportan los datos entre el servidor y el navegador. XML era el estándar, pero JSON, por ser más ligero y nativo de JavaScript, lo ha barrido del mapa en la práctica.
Cómo funciona una petición AJAX: te lo explico paso a paso
Vale, vamos a la práctica. Imagina que estás en una tienda online y quieres añadir un producto al carrito. Haces clic en el botón «Añadir al carrito» y el iconito del carrito se actualiza con un «1» al instante, sin que la página parpadee.
Eso, amigo mío, es AJAX en estado puro. Esto es lo que ha pasado por detrás:
El paso a paso de la magia asíncrona
- El evento: Tú haces clic en el botón. Esto dispara un evento en JavaScript.
- El mensajero sale a escena: El código JavaScript crea un objeto
XMLHttpRequest. Este es nuestro mensajero. - La petición: El mensajero (XHR) se envía al servidor con una petición. Podría ser algo como: «Oye, servidor, el usuario con ID ‘123’ quiere añadir el producto ‘ABC’ a su carrito». Esta petición se hace en segundo plano, de forma asíncrona. Tú puedes seguir navegando por la página mientras tanto.
- El servidor procesa: El servidor recibe la petición, hace lo que tenga que hacer (actualizar la base de datos con el nuevo producto en el carrito) y prepara una respuesta.
- La respuesta: El servidor envía de vuelta una respuesta al navegador. Normalmente será en formato JSON, algo simple como
{"status": "ok", "items_in_cart": 1}. - La actualización: JavaScript estaba esperando esta respuesta. Cuando la recibe, usa el DOM para encontrar el iconito del carrito en el HTML y cambiar el número que muestra, poniendo un «1».
Y todo esto ocurre en milisegundos, sin que te enteres. Brutal, ¿verdad? Esa es la base de las aplicaciones web modernas, desde Facebook a Google Maps.
¿Sigue vivo AJAX en 2025? La cruda realidad
Esta es la pregunta del millón. Con la llegada de nuevas tecnologías, muchos se preguntan si AJAX está muerto. La respuesta es un rotundo NO, pero con matices importantes. La técnica AJAX está más viva que nunca, pero las herramientas para implementarla han evolucionado.
El relevo generacional: Fetch API y Axios
El objeto XMLHttpRequest original es un poco tosco y verboso de usar. Por eso, el desarrollo web moderno ha abrazado alternativas más limpias y potentes:
- Fetch API: Es el estándar moderno integrado en todos los navegadores para hacer peticiones de red. Usa un sistema de Promesas que hace el código mucho más legible y fácil de gestionar que los callbacks de XHR.
- Axios: Es una librería de terceros muy popular que funciona tanto en el navegador como en el servidor (Node.js). Simplifica aún más las cosas, ofreciendo funcionalidades extra como la cancelación de peticiones o la protección contra XSRF.
La verdad es que en proyectos nuevos que he gestionado en la actualidad, casi siempre optamos por Fetch o Axios. Pero, y esto es clave, siguen aplicando la misma filosofía AJAX: peticiones asíncronas para actualizar la UI dinámicamente.
AJAX vs. Fetch API: la batalla moderna (tabla comparativa)
Para que lo veas más claro, te he preparado una tabla comparativa. No se trata de ver cuál es «mejor», sino de entender sus diferencias para saber cuándo usar cada uno.
| Característica | AJAX (XMLHttpRequest) | Fetch API |
|---|---|---|
| Sintaxis | Más verbosa, basada en callbacks y eventos. | Más limpia y moderna, basada en Promesas. |
| Manejo de errores | Se gestiona con el evento onerror. No distingue errores de red de errores HTTP (ej: 404). |
Más lógico. Las promesas se rechazan solo en fallos de red. Los errores HTTP (4xx, 5xx) deben ser comprobados manualmente en la respuesta. |
| Soporte en navegadores | Universal. Funciona hasta en Internet Explorer. | Soportado por todos los navegadores modernos. No funciona en IE. |
| Envío de datos (body) | Admite varios tipos de datos directamente (String, FormData…). | Más flexible y estandarizado, pero requiere manejar objetos como Blob o BufferSource. |
| Mi recomendación | Úsalo solo si necesitas dar soporte a navegadores muy antiguos o en código legado. | La opción por defecto para cualquier proyecto web moderno en 2025. |
Ojo con el SEO: cómo AJAX puede fastidiar tu posicionamiento
Y aquí llegamos a mi terreno. Como consultor SEO, he visto auténticos desastres causados por un mal uso de AJAX. La interactividad es genial para el usuario, pero puede ser un dolor de cabeza para los robots de búsqueda.
El problema: Googlebot y el contenido dinámico
El problema de base es que Googlebot, el rastreador de Google, históricamente ha preferido el HTML plano y simple. Cuando una página carga contenido importante a través de AJAX (por ejemplo, la lista de productos de una categoría), Googlebot puede tener problemas para «ver» ese contenido.
Aunque Google ha mejorado muchísimo su capacidad para renderizar JavaScript, este proceso consume muchos más recursos y tiempo. En mi experiencia, he visto casos donde el contenido cargado dinámicamente tarda más en indexarse o directamente no se indexa. Ojo, esto es crítico. Si tu contenido más importante depende de una llamada AJAX, podrías estar siendo invisible para Google.
Soluciones que recomiendo: SSR y renderizado dinámico
Afortunadamente, en el sector lo tenemos claro y hay soluciones robustas para esto:
- Server-Side Rendering (SSR): En lugar de enviar una página vacía que se rellena con AJAX, el servidor «prepara» la página con todo el contenido importante y la envía ya montada al navegador. Frameworks como Next.js (para React) o Nuxt.js (para Vue) son brutales para esto.
- Renderizado Dinámico: Es una solución intermedia. Configuras tu servidor para que detecte si el visitante es un usuario real o un bot de búsqueda. Al usuario le sirves la versión normal con AJAX, y al bot le das una versión HTML plana y prerenderizada.
Mi consejo es claro: para contenido público y crucial para el SEO (fichas de producto, artículos de blog, páginas de servicios), asegúrate de que sea visible en el HTML inicial. Usa AJAX para la interactividad, no para cargar el contenido principal.
Lo que debes llevarte claro sobre AJAX
Si has llegado hasta aquí, ya sabes más de AJAX que el 90% de la gente. Quiero que te quedes con tres ideas clave. Primero, AJAX no es una tecnología, es el concepto de comunicación asíncrona que ha hecho la web moderna posible. Segundo, aunque las herramientas han cambiado (hola, Fetch API), la filosofía sigue siendo la misma. Y tercero, y más importante, úsalo con cabeza. Prioriza la experiencia de usuario sin sacrificar tu visibilidad en Google. Un buen equilibrio entre contenido estático y dinamismo es la clave del éxito.
Ahora te toca a ti. ¿Estás usando AJAX en tu web? ¿Te ha dado algún problema de SEO? Cuéntamelo en los comentarios, ¡me encantará leer tu caso!
Preguntas que siempre me hacen sobre AJAX
¿Necesito saber jQuery para usar AJAX?
Absolutamente no. De hecho, en 2025 te diría que es mejor no depender de jQuery para esto. En el pasado, $.ajax() de jQuery simplificaba mucho las cosas, pero hoy en día la Fetch API nativa de JavaScript es igual de fácil de usar, más potente y no requiere cargar una librería externa, lo que mejora la velocidad de tu web.
¿Es AJAX seguro?
AJAX en sí mismo es solo una técnica de comunicación; la seguridad depende de cómo la implementes. Como toda comunicación con un servidor, debes tomar precauciones: valida siempre los datos en el lado del servidor (nunca confíes en los datos del cliente), usa HTTPS para encriptar la comunicación y protégete contra ataques comunes como CSRF y XSS.
¿Puedo usar AJAX con cualquier lenguaje de backend?
Sí, sin duda. AJAX es una tecnología del lado del cliente (frontend). Le da igual si tu backend está hecho en PHP, Python, Java, Node.js o Ruby. Mientras tu servidor pueda recibir una petición HTTP y devolver una respuesta (preferiblemente en formato JSON), puedes usar AJAX para comunicarte con él.
¿Afecta AJAX a los Core Web Vitals?
Puede afectar, y mucho. Si abusas de las peticiones AJAX al cargar la página, puedes impactar negativamente en métricas como el Largest Contentful Paint (LCP) si el contenido principal se carga dinámicamente. Además, si una interacción del usuario (un clic) desencadena una carga AJAX lenta, puede empeorar el Interaction to Next Paint (INP). La clave es usarlo para cargas pequeñas y rápidas y asegurar que el contenido inicial crítico se sirva directamente en el HTML.
Referencias y fuentes
- Guía de introducción a AJAX de MDN – La documentación de referencia para desarrolladores web, explicando los fundamentos.
- Documentación de la Fetch API en MDN – Información técnica completa sobre la alternativa moderna a XMLHttpRequest.
- Conceptos básicos de SEO con JavaScript (Google Search Central) – Guía oficial de Google sobre cómo rastrea e indexa sitios basados en JavaScript.
- «AJAX: A New Approach to Web Applications» por Jesse James Garrett – El ensayo original de 2005 que acuñó el término y definió el concepto.
- Documentación oficial de Axios – Guía de uso de una de las librerías más populares para realizar peticiones HTTP.
- Rendering on the Web (web.dev) – Un artículo detallado de Google que explica las diferencias entre renderizado en cliente (CSR), servidor (SSR) y otras técnicas.
