SEO técnico reproducible con IA: datos estructurados y redirecciones 301 que se pueden verificar

SEO técnico reproducible con IA: datos estructurados y redirecciones 301 que se pueden verificar

Cuando construyo o migro una web, casi siempre aparecen dos tareas de SEO técnico: añadir datos estructurados para que los buscadores entiendan el contenido, y redirigir las URLs antiguas a las nuevas sin perder lo que la web anterior había ganado. Las dos son tediosas de escribir a mano y fáciles de hacer mal sin darse cuenta. Y las dos son buenas candidatas para la IA, siempre que el resultado se trate como un borrador y se compruebe con herramientas independientes.

Con el tiempo convertí cada una en un procedimiento breve y reutilizable dentro de mis notas. El valor no está en el prompt, que es corto, sino en la secuencia: generar, validar con una herramienta y volver a validar con una segunda opinión.

Parte 1: datos estructurados con schema.org

Datos estructurados no es lo mismo que resultados enriquecidos

La primera distinción que tengo apuntada: los datos estructurados y los resultados enriquecidos están relacionados, pero no son lo mismo.

• Los datos estructurados son marcado, normalmente JSON-LD con el vocabulario de schema.org, que describe de qué trata una página: una organización, un negocio local, un producto, un artículo.
• Los resultados enriquecidos son los resultados ampliados que un buscador puede mostrar cuando encuentra datos estructurados válidos de un tipo compatible.

Tener datos estructurados válidos no garantiza un resultado enriquecido. Mantener separadas las dos cosas evita comprobar lo que no toca.

Generarlos

El primer prompt es deliberadamente abierto:

Dime qué datos estructurados de Schema añadirías en mi web.

Le paso la URL de la web o el HTML relevante, y la respuesta es una lista de tipos sugeridos con un script JSON-LD para cada uno. Para la web típica de un negocio pequeño el resultado se parece a esto (anonimizado con un ejemplo neutro):

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Studio",
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/example-studio",
    "https://www.instagram.com/example.studio"
  ]
}
</script>

Ese script va en el <head> de la página; en una web estática, dentro de index.html.

Después viene un segundo prompt, igual de corto, que recoge lo que se le escapó al primero:

Dime qué datos estructurados me faltan para que sea perfecto.

Preguntar por los huecos, en lugar de pedirlo todo de una vez, suele sacar a la luz propiedades y tipos que la primera respuesta había omitido.

Validarlos

El script nunca llega a producción solo porque lo haya generado el modelo. Lo valido dos veces, con dos herramientas distintas que responden a dos preguntas distintas:

1. El validador de schema.org (validator.schema.org): ¿el marcado es sintácticamente válido y los tipos son correctos?
2. La prueba de resultados enriquecidos de Google (search.google.com/test/rich-results): ¿esta página puede optar a algún resultado enriquecido?

Si pasa la primera y no la segunda, el marcado está bien, pero el tipo no es de los que generan un resultado ampliado: justo la distinción entre datos estructurados y resultados enriquecidos de antes. También compruebo cada valor contra la realidad: un modelo rellena sin problema un teléfono o una ruta de logo verosímiles que no existen.

Parte 2: redirecciones 301 sin bucles

El problema

En una migración, cada URL antigua que ya tiene tráfico o enlaces necesita una redirección permanente a su equivalente nueva. En un hosting con Apache eso suele significar líneas RewriteRule en el .htaccess. Escribir decenas a mano es propenso a errores, y los fallos típicos son sutiles: bucles de redirección, dobles barras o reglas que se encadenan en varios saltos.

El prompt como especificación

Aquí el prompt es menos una pregunta y más una especificación. Estos son los requisitos que incluyo siempre:

• Correspondencia 1:1 entre cada URL de origen y su destino.
• Redirecciones 301 permanentes.
• Sin bucles ni dobles barras (//).
• Una regla global que redirija cualquier URL pedida sin barra final a su versión con barra final, salvo cuando el último segmento parezca un archivo (contiene un punto).
• La salida como un único bloque completo, listo para pegar dentro de <IfModule mod_rewrite.c>.

Después de los requisitos va el mapeo, una línea por URL:

https://oldsite.example.com/en/tickets -> https://newsite.example.com/en/tickets/
https://oldsite.example.com/es/entradas -> https://newsite.example.com/es/entradas/
https://oldsite.example.com/fr/billets -> https://newsite.example.com/fr/billets/

Escribir los requisitos de forma explícita importa más que la redacción. Un modelo al que se le pide "crea unas redirecciones" producirá algo que parece correcto; un modelo al que se le dan las restricciones de bucles y barras suele escribir patrones que las respetan.

Un ejemplo anonimizado del tipo de bloque que espero recibir:

<IfModule mod_rewrite.c>
    RewriteEngine On

    # Mapeos 1:1 específicos. La barra opcional (/?) acepta ambas variantes
    RewriteRule ^en/tickets/?$ https://newsite.example.com/en/tickets/ [R=301,L]
    RewriteRule ^es/entradas/?$ https://newsite.example.com/es/entradas/ [R=301,L]
    RewriteRule ^fr/billets/?$ https://newsite.example.com/fr/billets/ [R=301,L]

    # Regla global: añadir barra final a las rutas que no parecen archivos
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_URI} !\.[A-Za-z0-9]+$
    RewriteCond %{REQUEST_URI} !/$
    RewriteRule ^(.*)$ /$1/ [R=301,L]
</IfModule>

Revisar el orden

Algo que siempre reviso a mano es el orden de las reglas. Apache procesa las reglas de arriba abajo, y [L] se detiene en la primera coincidencia. Si la regla global de la barra final se ejecuta primero en el dominio antiguo, una petición a /en/tickets se redirige primero a /en/tickets/ en el mismo dominio y solo después a la web nueva: dos saltos donde bastaría uno. Poner primero los mapeos específicos, con patrones que acepten la URL con o sin barra, evita esa cadena. Elija el modelo el orden que elija, me aseguro de que sea una decisión consciente.

Validarlas

Igual que con los datos estructurados, nada se despliega porque lo diga el modelo:

1. Un comprobador de .htaccess (technicalseo.com/tools/htaccess/): pego las reglas y pruebo URLs de origen reales para ver exactamente dónde acaba cada una.
2. Una segunda IA como revisora, con una pregunta acotada:

Analiza este htaccess y dime si provocaría un error crítico.

Un revisor que no ha escrito las reglas las mira de otra forma, y preguntar específicamente por errores críticos mantiene la respuesta centrada en bucles, sintaxis rota y reglas inalcanzables, en lugar de en el estilo.

Solo después de las dos comprobaciones suben las reglas al servidor, y aun así pido unas cuantas URLs antiguas en el navegador justo después del despliegue.

Por qué los guardo como procedimientos

Ninguno de los dos procedimientos es sofisticado. Lo importante es que están escritos y son repetibles: los mismos prompts, los mismos requisitos, los mismos dos pasos de validación independientes, cada vez. La IA hace que el primer borrador salga rápido. El procedimiento escrito y las herramientas de validación son lo que hace que el resultado sea fiable.