Skal en kundehistorie være en side, et innlegg eller en egen innholdstype? Spørsmålet virker beskjedent, men svaret påvirker redigering, navigasjon, søk, filtrering, ytelse og videreutvikling. Velger dere feil, fungerer nettstedet gjerne likevel – helt til noen skal oppdatere 40 medarbeiderprofiler, lage en oversikt eller gjenbruke innholdet et annet sted.
Mange WordPress-nettsteder starter med sider til alt. Det er forståelig: Sider er synlige, kjente og enkle å opprette. Etter noen år ligner administrasjonen en roteskuff med søkefelt. Alt ligger der, men ingen vil love at de finner riktig ladekabel.
En god innholdsmodell handler ikke om å gjøre WordPress mer avansert. Den skal skille mellom ulike typer innhold slik at redaktørene får færre valg, innholdet blir mer konsistent og utviklerne slipper å tolke overskrifter og tekstfelt som om de var arkeologiske funn.
Start med innholdets funksjon, ikke utseendet
Det vanligste feilgrepet er å velge struktur ut fra hvordan innholdet ser ut på én bestemt side. Et arrangement vises kanskje som et kort med bilde, dato og knapp. Det betyr ikke at «kort» er en innholdstype. Kortet er en presentasjon. Arrangementet er selve innholdet.
Før dere velger løsning, bør dere beskrive innholdet uten å nevne design. Still disse spørsmålene:
- Skal det finnes mange forekomster av samme type innhold?
- Har alle forekomstene de samme opplysningene, som dato, sted, rolle eller pris?
- Skal innholdet kunne listes, filtreres eller sorteres?
- Skal samme informasjon vises flere steder på nettstedet?
- Har innholdet en tydelig livssyklus, for eksempel kommende, gjennomført eller utløpt?
- Trenger redaktørene en egen oversikt i WordPress-administrasjonen?
Hvis flere av svarene er ja, er det ofte grunnlag for en egen innholdstype. Hvis innholdet derimot er unikt, forholdsvis stabilt og bare skal finnes på ett sted, holder en vanlig side som regel lenge.
Når bruker dere side, innlegg og egen innholdstype?
Bruk sider til varig og hierarkisk innhold
Sider passer til innhold som «Om oss», «Kontakt», tjenesteområder og informasjon som har en fast plass i nettstedets struktur. De kan organiseres som foreldre og undersider, men hierarkiet bør brukes med måte. Et organisasjonskart forkledd som hovedmeny er fortsatt et organisasjonskart, bare med dårligere plass.
En side er et godt valg når innholdet er unikt og redaktøren trenger frihet til å kombinere tekst, bilder og seksjoner. Gutenberg fungerer godt til dette, særlig når virksomheten har definerte blokkmønstre og noen tydelige rammer for layout.
Bruk innlegg til løpende publisering
Innlegg passer til nyheter, fagartikler, pressemeldinger og annet datert innhold som publiseres fortløpende. De har naturlig støtte for publiseringsdato, forfatter, kategorier, stikkord og arkiver.
Ikke bruk innlegg bare fordi noe skal vises i en liste. En oversikt over ansatte eller tjenester kan også listes, men innholdet er ikke nødvendigvis redaksjonelt eller kronologisk. Hvis publiseringsdatoen ikke betyr noe for leseren, er det et tegn på at innlegg kanskje er feil modell.
Bruk egne innholdstyper til gjentakende, strukturerte enheter
En egen innholdstype passer når dere har mange elementer med samme formål og datastruktur. Typiske eksempler er medarbeidere, lokasjoner, arrangementer, referanseprosjekter, kurs, stillinger og produkter uten netthandel.
Hver type kan få egne felter og egne regler. En medarbeider kan for eksempel ha navn, stilling, avdeling, telefonnummer, bilde og biografi. Da kan kontaktinformasjonen gjenbrukes på profilsiden, avdelingssiden og i en kontaktoversikt uten at redaktøren skriver den inn tre ganger.
Det finnes plugins som lover å opprette alle tenkelige innholdstyper, felt, filtre og relasjoner før lunsj. Noen er gode. Andre tilsvarer å kjøpe en gaffeltruck for å flytte en kaffekopp: imponerende kapasitet, litt mye vedlikehold og overraskende mange knapper.
Gutenberg løser presentasjonen, ikke innholdsmodellen
Gutenberg-blokker bestemmer hvordan innhold bygges og presenteres i redigeringsflaten. De erstatter ikke behovet for å definere hva innholdet faktisk er. En redaktør kan bygge en medarbeiderprofil med overskriftsblokk, bildeblokk og avsnitt, men WordPress vet fortsatt ikke hvilket avsnitt som er telefonnummeret.
Skill derfor mellom tre nivåer:
- Strukturerte felter lagrer opplysninger som skal gjenbrukes, valideres, sorteres eller filtreres.
- Gutenberg-blokker brukes til fleksibelt redaksjonelt innhold og presentasjon.
- Blokkmønstre gir redaktøren et anbefalt utgangspunkt for en bestemt seksjon eller sidetype.
Et blokkmønster er som en pepperkakeform: Det hjelper dere å starte med riktig fasong, men det lagrer ikke alle pepperkakene som én databasepost. Hvis innholdet må kunne hentes automatisk og vises flere steder, bør det ligge strukturert – ikke bare visuelt riktig.
En praktisk kombinasjon er å bruke faste felter til opplysninger som må være korrekte, og Gutenberg til beskrivende innhold. På et referanseprosjekt kan kunde, bransje og leveranse være strukturerte felter, mens selve historien bygges med godkjente blokker. Redaktøren får fleksibilitet uten at sentrale data forsvinner inn i tilfeldige tekstfelt.
Velg en modell som tåler redigering og vedlikehold
Før utvikling bør dere teste modellen med ekte innhold. Opprett tre til fem representative eksempler, inkludert den vanskelige varianten som alltid dukker opp etter lansering. Hvis ett kurs går over flere datoer, én medarbeider tilhører to avdelinger eller en lokasjon mangler besøksadresse, må modellen håndtere det uten kreative omveier.
Avklar også hva som skal skje når innhold endres. Hvis en medarbeider slutter, skal profilen slettes, avpubliseres eller arkiveres? Hvis et arrangement er gjennomført, skal det bli liggende med historisk informasjon? Slike regler bør være en del av arbeidsflyten, ikke noe neste redaktør må gjette seg til.
Vær særlig oppmerksom på avhengigheter. En egen innholdstype kan registreres i nettstedets kode eller gjennom en utvidelse, men løsningen bør dokumenteres og kunne flyttes. Kritiske data bør ikke bli uleselige fordi én plugin deaktiveres. Kortkoder som ligger igjen i innholdet etter en gammel sidebygger, er nettbransjens svar på geologiske sedimenter: lag på lag, og ingen er helt sikre på hva som lever nederst.
Strukturen påvirker også ytelsen. Automatisk genererte oversikter bør hente bare innholdet og feltene de trenger. Filtrering på mange løse tekstverdier kan gi unødvendig tunge spørringer, mens tydelige taksonomier og konsekvente felter gjør løsningen enklere å optimalisere. Det er sjelden nødvendig å installere en «AI-drevet ytelsesmotor» for å rette opp en innholdsmodell som først burde vært ryddet.
En praktisk beslutningsrekkefølge
- Beskriv innholdet med konkrete eksempler.
- Skill data fra presentasjon og layout.
- Velg side for unikt og stabilt innhold.
- Velg innlegg for datert, løpende publisering.
- Velg egen innholdstype for gjentakende enheter med felles struktur.
- Bruk taksonomier når innhold skal grupperes eller filtreres.
- Bruk faste felter til data som skal gjenbrukes eller valideres.
- Bruk Gutenberg og blokkmønstre til den redaksjonelle presentasjonen.
- Test modellen med reelle unntak før dere bygger alle malene.
- Dokumenter eierskap, publiseringsregler og tekniske avhengigheter.
Den beste innholdsmodellen er ikke den med flest innholdstyper. Den er den redaktørene forstår, som dekker faktiske behov og som kan vedlikeholdes uten at hver endring blir et lite konsulentprosjekt. WordPress er fleksibelt nok til å romme nesten enhver struktur. Nettopp derfor lønner det seg å velge med vilje.
