Cómo redujimos nuestro modelo de contenido de 12 tipos a 6
Consolidamos el modelo de contenido detrás de wilkesliberty.com de doce tipos de contenido a seis, sin migrar y sin romper una sola URL, y documentamos cómo lo hicimos. Esta es la versión corta; la historia de ingeniería está en el informe técnico.
El problema: un modelo de contenido que creció a oscuras
Los tipos de contenido se acumulan. Un sitio empieza con un puñado y, unas campañas después, tiene una docena, varios de ellos casi duplicados que solo difieren en uno o dos campos. El nuestro había llegado a doce. Los editores tenían que adivinar a qué tipo pertenecía una página nueva; el front end llevaba una rama por cada uno; y los campos de SEO estaban dispersos de forma distinta en cada tipo. Nada de eso estaba roto, exactamente. Solo era más pesado que el sitio que describía.
Qué hicimos
- Doce tipos se convirtieron en seis: Página básica, Recurso, Solución, Evento, Persona y Carrera, cada uno con una función clara y sin solapamientos.
- Tres tipos de oferta se fusionaron en uno. Los antiguos tipos Capacidad, Industria y Plataforma se integraron en un único tipo Solución clasificado por una taxonomía
solution_type, de modo que "qué hacemos" y "a quién servimos" comparten un modelo en lugar de tres. - Todas las URL sobrevivieron. La consolidación se hizo sin migrar: se preservaron las identidades de los nodos y los alias de ruta, de modo que ningún enlace externo, marcador o resultado de búsqueda se rompió, y no hay un muro de redirecciones que mantener.
- El SEO pasó a ser editable. Un único campo estructurado de metaetiquetas reemplazó el mosaico de SEO por tipo y por campo, de modo que los títulos y las descripciones se escriben en un solo lugar coherente en todos los tipos.
Por qué importa
El resultado es un modelo más sencillo de redactar, más sencillo de renderizar y más barato de cambiar, sin nada de la deuda de URL que habría creado una reconstrucción total. Es un patrón que cualquier sitio con mucho contenido puede tomar prestado: consolidar hacia el conjunto más pequeño de tipos que aún exprese las distinciones reales, y hacerlo sin migrar para que el cambio sea invisible para todos fuera del CMS.
Para la historia de ingeniería completa —cómo colapsamos los tipos sin tiempo de inactividad, mantuvimos estables las identidades y desenredamos la duplicación de campos que se había acumulado por el camino—, lea el informe técnico Colapsar un modelo de contenido sin migrar.