Webs hechas con IA: SEO, velocidad y decisiones que requieren un profesional

Una web hecha con inteligencia artificial puede verse terminada y seguir teniendo problemas de SEO, velocidad y accesibilidad. Lo encuentro en sitios que se publican sin una revisión profesional: la portada resulta atractiva, pero el menú responde tarde, el contenido queda mal organizado o una renovación pierde parte del trabajo que había permitido aparecer en Google. La herramienta genera una solución; alguien tiene que entenderla, probarla y hacerse responsable de publicarla.

Soy Daniel Esteban Waisman, de DWVisual. Me interesa hablar de esto porque desarrollar una web exige decisiones que muchas veces quedan fuera de la conversación. Pedirle a Gemini, ChatGPT o Claude que haga una página puede servir para empezar. Después hay que resolver cómo funciona, qué recursos necesita, quién podrá usarla y cómo se conservará su visibilidad. Esa parte requiere conocimientos y criterio profesional.

El cliente que renovó su web con IA y perdió visibilidad

Con un cliente habíamos hablado de renovar su sitio. Veníamos trabajando desde hacía años y habíamos conseguido que apareciera primero en Google. La conversación sobre el rediseño quedó pendiente y pasamos un tiempo sin contacto. Cuando vi que la web ya estaba renovada, le pregunté cómo la había hecho. Me respondió que la había desarrollado él mismo con inteligencia artificial.

Al volver a buscarla, encontré el sitio en la cuarta página de Google. Además, observé lentitud, problemas de accesibilidad, errores en la organización del contenido y dificultades para una navegación clara, también pensando en agentes de IA. La nueva apariencia había llegado acompañada de problemas que afectaban el uso y la presencia de la empresa en internet.

Cuento esta experiencia sin identificar al cliente porque me interesa explicar el riesgo. Esa observación no demuestra que una herramienta concreta haya causado toda la caída: para atribuirla hay que revisar consultas, fechas, cambios e información de Search Console. Sí muestra por qué considero imprescindible evaluar una renovación completa antes de reemplazar una web que ya tenía trabajo de posicionamiento.

La IA necesita a alguien que pueda evaluar lo que entrega

Mi objeción aparece cuando se confunde la capacidad de generar una página con la capacidad de dirigir un proyecto web. Una persona sin formación puede aceptar código que parece funcionar y desconocer lo que falta. Tal vez nunca se preguntó qué ocurre si falla una petición, cómo navega alguien con teclado o qué sucede con las direcciones del sitio anterior.

La IA puede ayudar a escribir, programar y explorar alternativas. El valor profesional está también en formular el problema, seleccionar una solución y detectar sus consecuencias. Si pedís una animación sin considerar el dispositivo, las preferencias de movimiento o la carga de recursos, podés obtener exactamente lo que pediste y perjudicar la experiencia.

Google explica en su orientación sobre contenido generado con IA que su enfoque se centra en la calidad, independientemente de cómo se produzca. Usar IA no implica por sí mismo una penalización. En una web, mi revisión se concentra en el resultado publicado y en las decisiones que lo sostienen.

Una web puede cargar y responder tarde

El problema que dio origen a esta nota sigue siendo muy concreto: la pantalla parece lista, tocás el menú y no pasa nada. Volvés a tocarlo y termina abriéndose y cerrándose. O elegís un filtro, esperás sin información y dudás de si tu selección fue tomada. Para quien intenta consultar un servicio, esas demoras forman parte de la calidad de la web.

Por eso me interesa probar tareas completas. Abrir una ficha, buscar una categoría, cambiar una opción y llegar al contacto permite descubrir dificultades que una captura de pantalla nunca muestra. También quiero saber qué sucede después de un error y si la persona puede continuar sin volver a escribir todo.

Interaction to Next Paint, o INP, mide la capacidad de respuesta de la página a interacciones como clics, toques y uso del teclado. Un valor de hasta 200 milisegundos se considera bueno; para evaluar el sitio se observa el percentil 75 de las visitas. La métrica llega hasta la siguiente actualización visual: no equivale al tiempo total que tarda un formulario en entregar un mensaje.

JavaScript: decidir qué cargar y en qué momento

Cuando reviso una implementación, quiero entender para qué está cada recurso. Un componente de reservas puede ser necesario en la página donde se utiliza. Cargar su código en todas las secciones merece una justificación. Lo mismo sucede con galerías, mapas, efectos y herramientas externas: cada incorporación necesita una razón relacionada con el uso del sitio.

También importa cuándo se ejecuta ese código. Diferir una carga, dividir un componente o activarlo cuando hace falta son decisiones que hay que probar. Mover todos los scripts al final o aplicar una opción automática de optimización puede romper dependencias. Prefiero identificar el problema y comprobar el comportamiento de los elementos afectados.

Un ejemplo: si agregamos un mapa para mostrar cómo llegar, quiero evaluar si hace falta descargarlo al entrar o si alcanza con activarlo cuando la persona lo consulta. También probaría cómo se encuentra la dirección si el mapa falla. Esa decisión combina rendimiento, información y uso; necesita entender para qué existe el componente.

La relación con el SEO también exige atención. La documentación de Google sobre JavaScript explica que Google puede ejecutar este lenguaje, pero distingue rastreo, renderizado e indexación. No todos los robots tienen esa capacidad. Revisar el HTML entregado, los enlaces y el contenido renderizado ayuda a elegir una arquitectura adecuada para cada proyecto.

PHP, servidor y administración también forman parte del trabajo

En un sitio WordPress, buena parte del trabajo ocurre antes de que el navegador muestre la página. PHP, la base de datos, el tema y los plugins intervienen en la respuesta del servidor. Si una sección tarda, necesito distinguir si la demora está ahí, en la descarga de recursos o en lo que ejecuta el dispositivo.

Una configuración de caché requiere conocer el contenido. Una nota pública y un carrito tienen comportamientos diferentes. También revisaría consultas innecesarias, funciones duplicadas y componentes que agregan trabajo sin aportar algo útil. Elegir una tecnología o instalar un plugin no resuelve automáticamente esas decisiones.

Pienso además en quien administrará la web. Si para cambiar un servicio hay que pedirle a una IA que reescriba archivos, la autonomía del cliente queda limitada por su capacidad para revisar código. Prefiero que las tareas habituales tengan campos claros y una forma previsible de editar, guardar y corregir. El mantenimiento empieza a definirse durante el desarrollo.

Para evaluar esa administración, pediría hacer una tarea habitual: cambiar una descripción y su fotografía, comprobar el resultado y recuperar la versión anterior si hubo un error. Eso permite saber si el sistema acompaña el trabajo cotidiano. Una web que exige asistencia técnica para cada modificación puede terminar desactualizada, aunque al entregarla tuviera todos sus textos completos.

Optimizar imágenes exige mirar cómo se usan

Una foto puede verse bien y pesar mucho más de lo necesario para el espacio que ocupa. Yo evaluaría su tamaño visible, el recorte, el formato y la calidad de exportación. También comprobaría qué versión recibe un teléfono. Una imagen pensada para una pantalla grande no debería enviarse por costumbre a todos los dispositivos.

El momento de carga requiere el mismo cuidado. La guía de carga diferida de imágenes de web.dev recomienda reservarla para imágenes fuera de la primera vista y evitarla en las que deben aparecer al entrar, especialmente la imagen principal. Declarar dimensiones también ayuda a reservar su espacio y evitar que el contenido salte mientras carga.

Para mí, la revisión termina cuando compruebo la imagen dentro de la página. Quiero ver si el texto de una pieza se lee en móvil, si el recorte conserva lo importante y si la compresión dañó detalles. Cambiar una extensión o marcar una casilla de “optimizar” deja pendientes esas decisiones visuales.

El SEO se trabaja en la estructura y en el contenido

Me preocupa especialmente que se considere el SEO una tarea para después de publicar. Antes de diseñar, conviene saber qué ofrece la empresa, qué necesita encontrar su público y cómo se organizarán los servicios. Un sitio puede tener muchas secciones y explicar poco. También puede reunir temas distintos en una sola página y dificultar que cada uno tenga un desarrollo útil.

En los encabezados busco una estructura comprensible: un título principal que identifique el tema, H2 para sus secciones y H3 cuando hay una subdivisión real. Elegirlos por el tamaño de letra produce una jerarquía confusa. No atribuiría una caída en Google a contar H1; revisaría cómo está organizado y presentado el contenido completo.

También comprobaría títulos y descripciones, enlaces internos, URL canónica, instrucciones de indexación y sitemap. Cada elemento debe corresponder con la página real. Cuando una empresa trabaja en diferentes localidades, esa misma planificación necesita información específica, como explico en la nota sobre SEO para zonas de servicio y contenido local.

En el contenido, buscaría respuestas que ayuden a decidir: qué incluye un servicio, para quién sirve y cómo se inicia una consulta. Si una herramienta entrega frases que podrían pertenecer a cualquier empresa, todavía falta trabajo. El conocimiento del negocio tiene que aparecer en la web para que el visitante entienda por qué elegir ese servicio y pueda plantear una necesidad concreta.

Renovar una web requiere cuidar lo que ya funcionaba

Antes de sustituir un sitio, me interesa conocer sus páginas y el papel que cumple cada una. Puede haber contenidos que reciben visitas, enlaces compartidos hace años o fichas que responden a búsquedas concretas. Si la renovación los elimina, el nuevo diseño cambia también la forma en que las personas llegan a la empresa.

Cuando cambian las direcciones, hay que relacionar las anteriores con destinos equivalentes y configurar las redirecciones pertinentes. Enviar todo a la portada no conserva el propósito de cada página. Google incluye la preparación de ese mapa, las redirecciones y el seguimiento entre sus recomendaciones para migrar un sitio.

Mi criterio es que una renovación necesita inventario, respaldo y comprobaciones antes y después de publicarse. Aunque el aspecto cambie por completo, hay información y recorridos que merecen conservarse. Por eso conviene conversar con un profesional antes de reemplazar una web posicionada, cuando todavía se puede planificar la transición.

La accesibilidad permite que más personas usen la web

La inclusión tiene consecuencias concretas en el diseño. Una persona puede necesitar navegar con teclado, ampliar el contenido o utilizar un lector de pantalla. Si el menú depende de pasar el mouse, el formulario carece de etiquetas o el foco desaparece, encuentra barreras para hacer una consulta que otra persona completa con facilidad.

Las recomendaciones de desarrollo accesible de W3C WAI incluyen controles etiquetados, alternativas textuales, estructura semántica, acceso por teclado y ayuda para corregir errores. Son aspectos que requieren atención durante la implementación. El texto alternativo también debe responder a la función de la imagen, en lugar de repetir palabras clave sin aportar información.

Yo quiero evaluar un recorrido que una persona pueda completar: encontrar el servicio, entenderlo y contactar. Una herramienta automática puede señalar errores, pero todavía hace falta revisar la interacción. Cuando alguien queda fuera por una decisión de diseño, hay un problema que merece corregirse aunque la portada se vea bien.

Una web comprensible también facilita la navegación de agentes

Al pensar en navegación agéntica, me interesa una pregunta práctica: ¿un asistente que recorre la web puede encontrar el servicio adecuado y explicar cómo consultar? Para evaluarlo, usaría tareas concretas. Si el contenido esencial está oculto en una imagen, un botón tiene un nombre ambiguo o faltan enlaces claros, la interpretación se vuelve más difícil.

Mi enfoque parte de información visible, nombres descriptivos y relaciones comprensibles entre páginas. Los datos estructurados pueden ayudar a describir entidades cuando reflejan el contenido real. También hay que distinguir las herramientas que leen HTML de las que interactúan con un navegador: no todas recorren una interfaz de la misma manera.

Agregar un archivo o una etiqueta no demuestra que el sitio sea fácil de usar por un agente. Prefiero comprobar qué puede localizar, qué interpreta correctamente y dónde necesita ayuda. Es una extensión del trabajo de claridad y organización que ya exige una web profesional, con pruebas acordes a la tarea.

Qué revisaría antes de dar una web por terminada

La entrega debería permitir comprobar decisiones. Yo comenzaría por un recorrido desde el teléfono: entrar por una página de servicio, abrir el menú, consultar información y llegar al contacto. Después repetiría las acciones con teclado y revisaría los estados de carga, éxito y error. Así aparecen problemas que quedan ocultos al mirar únicamente la portada.

Para el rendimiento, separaría pruebas controladas de datos de visitantes reales. Registrar dispositivo, conexión y tarea permite comparar cambios con más criterio. Una buena puntuación aislada no me alcanza para afirmar que un sitio funciona bien: también necesito comprobar que los formularios, filtros y demás funciones conservan su utilidad.

Al contratar una web, podés pedir explicaciones concretas: cómo conservarán las URL anteriores, qué podrás editar y cómo comprobarán la accesibilidad y el funcionamiento. Una respuesta profesional debería relacionar las decisiones con tu negocio y dejar claro qué se verificó. Eso te permite evaluar el trabajo más allá de una demostración visual.

Hablemos antes de publicar o renovar tu sitio

Entiendo el atractivo de resolver una web por cuenta propia. Las herramientas hacen posible avanzar muy rápido y experimentar sin depender de otra persona. Mi preocupación aparece cuando esa facilidad lleva a publicar algo que representa a una empresa sin revisar sus consecuencias. Los errores pueden quedar a la vista recién cuando cuesta encontrar el sitio o usarlo.

Mi trabajo en DWVisual es tomar esas decisiones con criterio y relacionar diseño, desarrollo y contenido con lo que necesitás conseguir. Podés conocer el enfoque de desarrollo web de DWVisual o consultarme por una página que ya tengas. Si usaste IA para crearla, ese material puede servir como punto de partida para revisar qué funciona y qué necesita cambiar.

Antes de reemplazar tu web actual o publicar una nueva, escribime y contame qué necesitás. Soy Daniel Esteban Waisman y puedo ayudarte a evaluar el proyecto, definir sus prioridades y trabajar sobre una web que las personas puedan encontrar, comprender y usar.

Más sobre el autor y sus ideas en las notas de opinión de Daniel Waisman.