rafa/feadulta
1
0
Fork 0
Code Issues 71 Pull Requests 5 Actions Packages Projects Releases Wiki Activity

Banner en el archivo estático: ofrecer la misma página en el WordPress nuevo #187

New Issue
Open
opened 2026-07-31 18:27:00 +00:00 by rafa · 0 comments
rafa commented 2026-07-31 18:27:00 +00:00
Owner
Copy Link
Copy Source

Idea

El archivo estático (antiguo.feadulta.com) recibe más sesiones que el sitio vivo, pero se comporta como un callejón sin salida: la gente entra por un enlace viejo, lee una página y se va. Si esa página existe en el WordPress nuevo, deberíamos ofrecerle ir a la versión buena.

Propuesta: un banner en las páginas del archivo que ofrezca ver esa misma página en el WordPress nuevo, con la condición estricta de que solo aparezca cuando el equivalente esté localizado con total certeza. Si no hay certeza, no hay banner. Un enlace que lleve a la página equivocada es peor que no ponerlo.

Datos que lo motivan (GA4, 7 días, 31-jul)

hostName sesiones usuarios páginas vistas páginas/sesión engagement
antiguo.feadulta.com 4.800 4.163 7.275 1,5 24%
www.feadulta.com 3.009 1.301 11.749 9,0 73%

Ese 1,5 vs 9,0 es el argumento entero: hay ~4.000 usuarios/semana entrando por la puerta vieja a los que hoy no les ofrecemos nada.

El mapeo existe y es fiable

Las URLs de artículo del archivo llevan el id de K2 en la propia ruta:

/es/buscadoravanzado/item/850-jesús-el-mesías-y-el-reino.html
                          ^^^ id de K2

y en WordPress cada post migrado conserva ese id en la meta _fgj2wp_old_k2_id (es la misma que ya usa fea-carta-portada.php para resolver posts). O sea que el emparejamiento no hay que adivinarlo por título ni por slug: es una clave primaria.

Criterio de "localizado perfectamente" propuesto:

  1. La URL del archivo encaja con item/<id>-<slug>.html.
  2. Existe exactamente un post WP con _fgj2wp_old_k2_id = <id>.
  3. Ese post está en estado publish (ni borrador, ni papelera, ni privado).
  4. Su URL final responde 200.

Si falla cualquiera de las cuatro → sin banner en esa página. Sin excepciones ni heurísticas de respaldo.

Implementación propuesta: en build, no en JavaScript

El archivo es HTML estático servido por nginx, y ya hemos hecho ediciones masivas sobre él con buen resultado (retirada del tag UA-32008163-1 en 27.393 ficheros, retirada de los bloques sociales en 16.708). El mismo método sirve aquí y evita depender de JS o de una llamada al WordPress en cada visita:

  1. Exportar de WP el mapa _fgj2wp_old_k2_id → permalink, solo posts publicados → JSON.
  2. Recorrer site/, extraer el id de K2 de cada ruta, y solo para los que cumplan los 4 criterios, inyectar el bloque del banner con el enlace ya resuelto.
  3. Verificar contra el WP que cada enlace inyectado responde 200 antes de sincronizar (hay precedente: verify_carta_lang_links.php).
  4. 80-sync-hetzner.sh como siempre.

Ventajas: cero JS, cero latencia, cero dependencia del WP en tiempo de visita, y el banner solo existe físicamente en las páginas donde se pudo resolver — el criterio se cumple por construcción.

Medición

El enlace debe llevar parámetros de campaña (p. ej. ?utm_source=archivo&utm_medium=banner) para que GA4 atribuya el salto y podamos responder a: ¿cuánta gente lo usa? ¿sube el engagement del sitio vivo? Ya hay trabajo previo de atribución UTM en feadulta_ga4_digest.py, y desde hoy ga4_report.py sabe filtrar por hostName (--host), que es lo que permite medir los dos sitios por separado.

Cosas a decidir antes de implementar

  • Texto y tono del banner. Es contenido de cara al público → lo decide Rafa/Inma, no yo. Algo del estilo "Estás viendo la versión antigua de esta página. Ver la versión actual".
  • Posición: arriba del contenido (más visible, más intrusivo) o al final del artículo (menos intrusivo, se lo encuentra quien ha leído). Se puede probar una y medir.
  • Páginas sin equivalente: ¿de verdad nada, o un aviso genérico sin enlace profundo ("esta es la web antigua, visita feadulta.com")? Mi recomendación: probar primero solo el caso con enlace resuelto, y decidir el genérico con los datos delante.
  • Portadas y páginas de sección (/es/, /es/effa.html, listados de autor): no tienen id de K2, así que quedan fuera del criterio. Se pueden mapear a mano si merece la pena — son pocas y concentran mucho tráfico.
  • Interacción con el noindex: el archivo está deliberadamente en noindex + robots.txt Disallow: / (decisión cerrada, ver #180) porque duplica el contenido del WordPress. El banner no cambia eso, pero conviene tenerlo presente: no añadir canonical al WP en estas páginas, que sería contradictorio con el noindex.

Alcance

No es bloqueante para la migración del 03-ago (#180) ni para el deadline del hosting.

Corrección (Rafa preguntó el porqué y tenía razón en dudar): escribí que hacerlo antes del cutover obligaría a recalcular el mapa de enlaces dos veces. Es falso. El cutover del 03-ago es un cambio de servidor, no de dominio: T2.6 hace search-replace a un hostname de staging y lo devuelve a www.feadulta.com con siteurl/home definitivos, "regenerar permalinks" es un flush de reglas de reescritura, y la BD viaja entera con la meta _fgj2wp_old_k2_id intacta. Mismo dominio, mismos slugs, misma meta → el mapa sale idéntico antes y después. El razonamiento venía de la analogía con el cutover de julio, que sí cambió URLs (Joomla → WordPress); éste no.

Lo que sí queda como motivo para no adelantarlo, y es de calendario y no técnico: no conviene mezclar un cambio que toca 25.000 ficheros del archivo con la semana de un deadline duro que tiene 4 días de margen. Si se quiere antes, es independiente del cutover y reversible (se regenera site/ y se sincroniza con 80-sync-hetzner.sh).

Refs #180

## Idea El archivo estático (`antiguo.feadulta.com`) recibe **más sesiones que el sitio vivo**, pero se comporta como un callejón sin salida: la gente entra por un enlace viejo, lee una página y se va. Si esa página existe en el WordPress nuevo, deberíamos ofrecerle ir a la versión buena. Propuesta: **un banner en las páginas del archivo que ofrezca ver esa misma página en el WordPress nuevo**, con la condición estricta de que **solo aparezca cuando el equivalente esté localizado con total certeza**. Si no hay certeza, no hay banner. Un enlace que lleve a la página equivocada es peor que no ponerlo. ## Datos que lo motivan (GA4, 7 días, 31-jul) | hostName | sesiones | usuarios | páginas vistas | páginas/sesión | engagement | |---|---|---|---|---|---| | antiguo.feadulta.com | 4.800 | 4.163 | 7.275 | **1,5** | **24%** | | www.feadulta.com | 3.009 | 1.301 | 11.749 | **9,0** | **73%** | Ese 1,5 vs 9,0 es el argumento entero: hay ~4.000 usuarios/semana entrando por la puerta vieja a los que hoy no les ofrecemos nada. ## El mapeo existe y es fiable Las URLs de artículo del archivo llevan el **id de K2 en la propia ruta**: ``` /es/buscadoravanzado/item/850-jesús-el-mesías-y-el-reino.html ^^^ id de K2 ``` y en WordPress cada post migrado conserva ese id en la meta **`_fgj2wp_old_k2_id`** (es la misma que ya usa `fea-carta-portada.php` para resolver posts). O sea que el emparejamiento no hay que adivinarlo por título ni por slug: es una clave primaria. **Criterio de "localizado perfectamente" propuesto:** 1. La URL del archivo encaja con `item/<id>-<slug>.html`. 2. Existe **exactamente un** post WP con `_fgj2wp_old_k2_id = <id>`. 3. Ese post está en estado `publish` (ni borrador, ni papelera, ni privado). 4. Su URL final responde 200. Si falla cualquiera de las cuatro → sin banner en esa página. Sin excepciones ni heurísticas de respaldo. ## Implementación propuesta: en build, no en JavaScript El archivo es HTML estático servido por nginx, y ya hemos hecho ediciones masivas sobre él con buen resultado (retirada del tag `UA-32008163-1` en 27.393 ficheros, retirada de los bloques sociales en 16.708). El mismo método sirve aquí y evita depender de JS o de una llamada al WordPress en cada visita: 1. Exportar de WP el mapa `_fgj2wp_old_k2_id` → permalink, solo posts publicados → JSON. 2. Recorrer `site/`, extraer el id de K2 de cada ruta, y **solo para los que cumplan los 4 criterios**, inyectar el bloque del banner con el enlace ya resuelto. 3. Verificar contra el WP que cada enlace inyectado responde 200 antes de sincronizar (hay precedente: `verify_carta_lang_links.php`). 4. `80-sync-hetzner.sh` como siempre. Ventajas: cero JS, cero latencia, cero dependencia del WP en tiempo de visita, y **el banner solo existe físicamente en las páginas donde se pudo resolver** — el criterio se cumple por construcción. ## Medición El enlace debe llevar parámetros de campaña (p. ej. `?utm_source=archivo&utm_medium=banner`) para que GA4 atribuya el salto y podamos responder a: ¿cuánta gente lo usa? ¿sube el engagement del sitio vivo? Ya hay trabajo previo de atribución UTM en `feadulta_ga4_digest.py`, y desde hoy `ga4_report.py` sabe filtrar por `hostName` (`--host`), que es lo que permite medir los dos sitios por separado. ## Cosas a decidir antes de implementar - **Texto y tono del banner.** Es contenido de cara al público → lo decide Rafa/Inma, no yo. Algo del estilo "Estás viendo la versión antigua de esta página. Ver la versión actual". - **Posición:** arriba del contenido (más visible, más intrusivo) o al final del artículo (menos intrusivo, se lo encuentra quien ha leído). Se puede probar una y medir. - **Páginas sin equivalente:** ¿de verdad nada, o un aviso genérico sin enlace profundo ("esta es la web antigua, visita feadulta.com")? Mi recomendación: probar primero solo el caso con enlace resuelto, y decidir el genérico con los datos delante. - **Portadas y páginas de sección** (`/es/`, `/es/effa.html`, listados de autor): no tienen id de K2, así que quedan fuera del criterio. Se pueden mapear a mano si merece la pena — son pocas y concentran mucho tráfico. - **Interacción con el `noindex`:** el archivo está deliberadamente en `noindex` + `robots.txt Disallow: /` (decisión cerrada, ver #180) porque duplica el contenido del WordPress. El banner no cambia eso, pero conviene tenerlo presente: **no** añadir `canonical` al WP en estas páginas, que sería contradictorio con el `noindex`. ## Alcance No es bloqueante para la migración del 03-ago (#180) ni para el deadline del hosting. **Corrección (Rafa preguntó el porqué y tenía razón en dudar):** escribí que hacerlo antes del cutover obligaría a recalcular el mapa de enlaces dos veces. **Es falso.** El cutover del 03-ago es un cambio de servidor, no de dominio: T2.6 hace `search-replace` a un hostname de staging y lo devuelve a `www.feadulta.com` con `siteurl`/`home` definitivos, "regenerar permalinks" es un flush de reglas de reescritura, y la BD viaja entera con la meta `_fgj2wp_old_k2_id` intacta. Mismo dominio, mismos slugs, misma meta → **el mapa sale idéntico antes y después**. El razonamiento venía de la analogía con el cutover de julio, que sí cambió URLs (Joomla → WordPress); éste no. Lo que sí queda como motivo para no adelantarlo, y es de calendario y no técnico: no conviene mezclar un cambio que toca 25.000 ficheros del archivo con la semana de un deadline duro que tiene 4 días de margen. Si se quiere antes, es independiente del cutover y reversible (se regenera `site/` y se sincroniza con `80-sync-hetzner.sh`). Refs #180
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
inma rafa
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: rafa/feadulta#187
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?