Plataforma Inmobiliaria: zamki-szkocji.com

#zamki-szkocji.com, tu guía a los castillos mágicos de Escocia

zamki-szkocji.com es un portal informativo dedicado a los castillos de Escocia: artículos históricos, un mapa interactivo, galerías de fotografías y vídeo, y notas prácticas para quien está preparando un viaje. Salió a producción en 2012, funciona sobre WordPress con Redis como caché de objetos y se apoya en infraestructura de AWS con una CDN delante de los archivos multimedia. La implementación llevó alrededor de seis semanas. El cliente entregó la maquetación y la disposición de los elementos; mi parte consistió en convertir esa maquetación en un modelo de contenido, plantillas e integraciones capaces de aguantar años de fichas nuevas.

#Dos lecturas que en las estadísticas parecen la misma

Un portal sobre castillos atiende a dos personas que los datos de tráfico apenas distinguen. Una lee por gusto y quiere un texto largo y bien contado sobre un lugar que quizá nunca visite. La otra tiene medio itinerario en la mano y necesita saber dónde está el castillo, si abre en marzo y cómo encaja entre dos paradas del mismo día. La primera necesita prosa. La segunda necesita datos.

Atender solo a la primera produce un sitio agradable al que nadie vuelve. Atender solo a la segunda produce un directorio sin motivo para ser leído. La arquitectura tenía que sostener las dos lecturas, y por eso el objeto central del sistema no es un artículo.

#Un castillo es un registro, no una entrada de blog

Cada castillo se modeló como un tipo de contenido propio con sus campos: coordenadas, indicaciones de acceso, región, periodo histórico, estilo arquitectónico, galería, material en vídeo y una línea de tiempo de los hechos ligados al edificio. En WordPress esto significa un tipo de contenido personalizado con sus propias taxonomías.

La diferencia aparece con el volumen. Con veinte fichas, las etiquetas bastan y cualquier alternativa parece exceso de ingeniería. Con varios centenares, las etiquetas dejan de ser una clasificación y se convierten en un montón de casi sinónimos: unas fichas dicen Highlands, otras dicen norte, algunas dicen las dos cosas, y ya nadie puede demostrar que una lista esté completa. Una taxonomía cerrada obliga a decidir en el momento de crear la ficha, cuando quien escribe todavía tiene la fuente delante.

El precio es la rigidez. El vocabulario hay que pensarlo antes, y cambiarlo después es una migración de datos, no una corrección de texto. Aquí el intercambio salía a cuenta, porque ni la geografía de Escocia ni la clasificación de la arquitectura defensiva se mueven de un año para otro. En un portal de eventos o de ofertas, donde el vocabulario acompaña al mercado, la misma decisión sería un error.

La línea de tiempo merece una nota aparte. Es tentador pegarla en el cuerpo del texto como marcado ya resuelto. El primer día queda bien y en cualquier otro sitio resulta inservible. Guardada como fechas y hechos, se puede presentar en varios formatos, ordenar y corregir en un único lugar el día en que alguien nota que dos fuentes datan de forma distinta la reforma de un ala.

#El mapa y los datos de geolocalización

El mapa interactivo usa la API de Google Maps junto con endpoints propios que devuelven los datos de ubicación en un formato pensado para dibujar marcadores. La separación no es cosmética. Si el mapa pidiera las entradas completas, cada carga arrastraría todo el texto histórico para pintar un punto y tres frases en un globo. Un endpoint dedicado devuelve solo lo que el mapa dibuja: respuesta pequeña, fácil de cachear e independiente de cada corrección en el artículo.

El segundo motivo es de mantenimiento. Los datos de ubicación pasan por un único sitio, así que reglas como no mostrar un objeto sin coordenadas, o no publicar en el mapa una ruina sin indicaciones de acceso, viven en el código y no en la costumbre de la redacción. En un sitio que crece durante una década, esa es la diferencia entre un mapa que refleja la base de datos y un mapa que alguien tiene que revisar a mano una vez al año.

Todo servicio externo de mapas trae el mismo compromiso. El proveedor aporta teselas, geocodificación y un comportamiento que el usuario ya conoce de otras páginas, y a cambio ata el proyecto a cuotas y políticas de claves ajenas. En lugar de fingir que ese coste no existe, se limita el número de llamadas: el mapa se carga cuando hace falta, no en cada página de listado, y las respuestas del endpoint propio se almacenan para que recorrer una lista no genere tráfico hacia el proveedor.

#Rendimiento, caché y multimedia

El rendimiento era la restricción real, y no se podía resolver aligerando la página. Las fotografías son el contenido: quitarlas habría mejorado la medición eliminando el motivo por el que alguien entra.

Redis se ocupa de la caché de objetos. Una página de WordPress se arma con muchas lecturas pequeñas: opciones, metadatos, relaciones de taxonomía. En una vista de archivo con decenas de fichas y sus campos, el número de esas lecturas crece más deprisa de lo que sugiere la cantidad de elementos visibles. Con los resultados fuera de la base de datos, la siguiente petición no repite el mismo trabajo. Eso ayuda justo donde la caché de página completa no llega: vistas con parámetros, el endpoint del mapa y cualquier petición de un editor autenticado.

La CDN se ocupa de los archivos multimedia. La fotografía de castillos pesa, y el público se reparte entre Polonia, las islas británicas y cualquier sitio desde el que alguien planifique unas vacaciones. Servir esos archivos desde un único origen significa que la mitad de los lectores espera una transferencia que cruza Europa cada vez. Entregarlos desde ubicaciones cercanas también quita al servidor de aplicación un trabajo que nunca le correspondió.

El tráfico de un sitio de viajes no se reparte de forma uniforme, y eso cambia qué ajuste vale la pena. Sube con la temporada y salta tras una mención en prensa o una publicación en un grupo temático grande. Afinar para la media mensual sirve de poco. Lo que cuenta es la hora en la que llegan muchas veces las visitas habituales, y en esa hora no salva el código más rápido, sino que la mayoría de las respuestas no lleguen siquiera a la aplicación.

Los tiempos de caché se fijaron a propósito y no se heredaron del valor por defecto de un plugin. La descripción de un castillo puede vivir horas en caché, cambia unas pocas veces al año. Un aviso de cierre temporal no puede, porque es exactamente la información que alguien busca la víspera del viaje. Separar ambos casos sale más barato que acortar la vida útil global, que degrada el rendimiento en todas partes para arreglar una sola vista.

Las galerías y el cambio de medios funcionan con AJAX, de modo que pasar de una fotografía a otra no recarga la página. El beneficio es evidente; el coste, menos. El contenido que solo existe después de ejecutar un script no existe para una parte de los visitantes: en el mal caso para un rastreador, en el peor para un lector de pantalla. La dirección de cada imagen y la descripción del objeto tienen que estar en el documento HTML normal, con AJAX acelerando la navegación y no sustituyéndola.

Las mediciones se hicieron contra una copia de producción, no contra una instalación vacía. Un WordPress recién instalado con un tema y dos entradas responde rápido siempre, se escriban como se escriban las consultas. Solo una base con el conjunto completo de fichas, sus metadatos, las relaciones de taxonomía y el historial de comentarios muestra qué consulta recorre media tabla y cuál aprovecha un índice.

En la parte de buscadores el trabajo fue HTML5 semántico, metadatos ordenados, direcciones legibles derivadas de la estructura y datos estructurados de schema.org para los artículos sobre castillos. El propósito es acotado: describirle a una máquina lo que una persona lee del diseño. Los datos estructurados no colocan un texto flojo por delante de uno bueno; evitan que un texto bueno pase inadvertido porque el rastreador no supo qué clase de página tenía delante. No dispongo de mediciones del efecto de ese trabajo que pueda citar con honestidad, así que no cito ninguna.

#Qué hacía valioso este portal

El valor estaba en reunir en un mismo lugar la inspiración de viaje y la información utilizable, y en que esa unión aguantara el paso de los años. Los comentarios y valoraciones permitían a los visitantes dejar su experiencia de un lugar, una función rápida de activar y cara de sostener: cualquier formulario abierto en una página visible en buscadores acaba encontrado por tráfico automatizado en cuestión de semanas. La lección práctica de esta implementación es moderar con dureza al principio y aflojar después, en vez de limpiar meses de enlaces basura bajo la descripción de una fortaleza del siglo XV.

El mantenimiento cubre actualizaciones del núcleo, el tema y los plugins, revisión de registros, copias de seguridad y cambios funcionales o visuales menores. En un sitio que lleva en marcha desde 2012, el mantenimiento es la mayor parte de la historia y conviene presupuestarlo así. Las actualizaciones se prueban sobre una copia, porque un proyecto con tipo de contenido propio, taxonomías propias e integración de mapas externa tiene varios puntos donde un cambio en el núcleo o en un plugin altera el comportamiento sin lanzar ningún error. Y una copia de seguridad es un procedimiento de restauración, no un archivo en un disco: la que vale es aquella con la que ya se ha levantado una copia funcional del sitio, anotando cuánto tardó.

Lo que viaja al siguiente proyecto es la capa técnica y el método: WordPress, Redis, AWS y CDN, datos estructurados y medición contra una copia de producción. Lo que no viaja es el modelo de contenido de este portal ni sus integraciones, escritos para un conjunto de datos y una forma de leer. Un encargo nuevo empieza por revisar el alcance, y el presupuesto llega después de esa revisión.