Cómo migrar un sitio de Oracle APEX a una web moderna sin perder posicionamiento

Oracle APEX es excelente para aplicaciones internas: formularios, reportes y flujos sobre Oracle Database, construidos muy rápido. Pero cuando se usa para el sitio público de un negocio, aparecen los problemas:

• URLs como /ords/f?p=123:5:1029384756::NO que Google no entiende bien y nadie puede recordar.
• Páginas lentas en celular.
• Poco control sobre metadatos, datos estructurados e imágenes para compartir.
• Cada cambio de contenido depende de un desarrollador APEX.

Migrar a una web moderna (por ejemplo Astro + React) resuelve eso, pero hay que hacerlo con cuidado para no perder los enlaces, los códigos QR impresos y el posicionamiento que ya tiene el sitio.

1. Entender las URLs de APEX

Las URLs clásicas de APEX tienen esta forma:

/ords/f?p=APP:PAGINA:SESION:REQUEST:DEBUG:CLEAR:ITEMS:VALORES

Lo que identifica la página es APP:PAGINA, por ejemplo 123:5. La sesión cambia en cada visita, así que no sirve para mapear. Algunas páginas además usan ITEMS:VALORES para mostrar un producto concreto (P5_ID:42).

2. Hacer el inventario

Antes de escribir código nuevo:

1. Exporta la aplicación APEX y lista todas sus páginas públicas.
2. Revisa en Google Search Console qué URLs reciben tráfico y cuáles están indexadas.
3. Pregunta dónde hay enlaces impresos: menús con QR, tarjetas, folletos, publicaciones en redes.
4. Arma una tabla: URL vieja → página nueva.

Ese mapa es el activo más importante de la migración.

3. Construir el sitio nuevo con buenas URLs

Con Astro cada página se genera como HTML estático con una URL limpia:

/productos/croissant-de-almendra/
/sucursales/
/menu/

Aprovecha para agregar lo que APEX no daba: título y descripción por página, datos estructurados (organización, productos, sucursales), imágenes Open Graph para WhatsApp y redes, sitemap y buena velocidad en celular.

4. Redirecciones 301 desde las URLs viejas

La clave es que cada URL de APEX responda con una redirección 301 a su equivalente nuevo. Así Google transfiere el posicionamiento y los QR siguen funcionando. Con Nginx se puede hacer con un map sobre el parámetro p:

# /etc/nginx/conf.d/apex-map.conf
map $arg_p $apex_destino {
    default                  "";
    "~^123:1(:|$)"           "/";
    "~^123:5(:|$)"           "/menu/";
    "~^123:8(:|$)"           "/sucursales/";
    "~^123:12:[^:]*:[^:]*:[^:]*:[^:]*:P12_ID:42"  "/productos/croissant-de-almendra/";
}

server {
    # ...
    location /ords/ {
        if ($apex_destino) {
            return 301 $apex_destino;
        }
        return 301 /;
    }
}

Si hay muchos productos, genera ese mapa con un script a partir de los datos, en lugar de escribirlo a mano.

5. Una transición sin riesgo

Lo que mejor me ha funcionado:

1. Publica el sitio nuevo en un subdominio de revisión (con noindex) para que el cliente lo apruebe con calma.
2. Mientras tanto, producción sigue igual.
3. El día del cambio, cambia la configuración del dominio principal, activa las redirecciones y envía el sitemap nuevo en Search Console.
4. Durante las siguientes semanas revisa en Search Console errores 404 o URLs sin redirección y agrégalas al mapa.

6. Qué esperar después

Es normal ver algo de movimiento en el posicionamiento durante unas semanas mientras Google procesa las redirecciones. Con un mapa completo de 301 y un sitio más rápido y mejor estructurado, lo habitual es recuperar y superar el tráfico anterior.

Si tienes un sitio en APEX que ya te quedó chico, te ayudo a migrarlo sin perder lo que ya ganaste.