Hvad er dynamiske sider i HubSpot?

Sådan virker dynamiske sider i HubSpot

Dynamiske sider har to mulige datakilder, og valget mellem dem afgør resten af opsætningen. Den ene er HubDB, HubSpots egne tabeller inde i portalen, hvor hver række bliver til en side. Den anden er CRM-objekter, altså de records du allerede har liggende på produkter, virksomheder eller et custom object. HubDB vælges, når data kun skal bruges på websitet. CRM-objektet vælges, når de samme data også skal bruges af salg og service, så du ikke ender med to versioner af sandheden.

Uanset kilde genererer HubSpot to slags sider. Oversigtssiden ligger på den URL, du selv vælger, og har adgang til hele datasættet. Detaljesiden ligger et niveau under og kender kun sin egen række. I skabelonen er forskellen en variabel: på oversigtssiden er dynamic_page_hubdb_table_id udfyldt, og du løber igennem rækkerne med funktionen hubdb_table_rows. På detaljesiden er dynamic_page_hubdb_row udfyldt med netop den rækkes værdier. Samme HubL-fil dækker begge tilstande, og det er derfor, 180 forhandlere kun kræver én skabelon.

URL-strukturen kommer fra to reserverede kolonner i tabellen. Den kolonne, du udpeger som page path, leverer hs_path, altså det sidste led i adressen, mens page title leverer hs_name. Ligger oversigten på /forhandlere, og har en række hs_path-værdien nordjysk-teknik, bliver detaljesidens adresse /forhandlere/nordjysk-teknik. HubSpot normaliserer stier til små bogstaver og matcher uanset versalisering, så et link med stort begyndelsesbogstav rammer stadig den rigtige side. Mekanikken er beskrevet i HubSpots udviklerdokumentation for HubDB-drevne dynamiske sider.

Selve skabelonen bygges i Design Manager som en template eller et custom modul med HubL. Det er her, langt de fleste projekter bruger deres timer. Tabellen tager en eftermiddag. Skabelonen skal derimod håndtere tomme felter, billeder i forskellige formater, sortering, filtrering og et fornuftigt udseende på mobil, og den skal kunne holde til, at nogen senere tilføjer en kolonne. Når den er færdig, kobles den til siden under Settings og derefter Advanced, hvor datakilden vælges i en dropdown.

Kører du på CRM-objekter i stedet, er der et krav mere. Den property, der skal levere URL-slug, skal være sat op med hasUniqueValue, og værdierne skal være små bogstaver uden mellemrum og uden specialtegn ud over bindestreg. Til gengæld får du felter for dynamic page title, meta description, featured image og canonical URL direkte på objektet. Standardobjekter som Products virker på Content Hub Professional, mens custom objects kræver Content Hub Enterprise eller Marketing Hub Enterprise kombineret med Content Hub Professional, hvilket fremgår af HubSpots dokumentation for dynamiske sider på CRM-objekter.

SEO-felterne fortjener en bemærkning, fordi de er den hyppigste kilde til dårlige dynamiske sider. I HubDB-tabellens indstillinger udpeger du de kolonner, der skal levere meta description, featured image og canonical URL til detaljesiderne. Skabelonen skal derefter kalde page_meta.meta_description og ikke content.meta_description. Gør den ikke det, arver alle detaljesider oversigtssidens tekst, og så har du 180 sider med samme meta description. Google behandler dem derefter.

HubDB har draft og published hver for sig, præcis som sider har. En række, du lige har oprettet, findes kun i draft, indtil tabellen publiceres, og det er den almindelige forklaring på, at en ny side svarer 404, selvom rækken tydeligvis står der. Det samme gælder ændringer i skemaet. Tilføjer du en kolonne og glemmer at publicere tabellen, renderer skabelonen tomt for det felt.

Grænserne er til at overskue, men de findes. Du kan oprette op til 10 dynamiske sider pr. datakilde, altså 10 pr. HubDB-tabel og 10 pr. CRM-objekt, og de genererede detaljesider tæller ikke med i det tal. HubDB-drevne dynamiske sider er begrænset til 50.000 opdateringer af søgeindekset pr. konto pr. dag, og et sæt dynamiske sider indekseres for op til 10.000 records. Uautentificerede GET-kald mod HubDB-API'et er sat til 10 i sekundet og tæller ikke mod det daglige loft. Trådene i HubSpots community peger desuden på et praktisk loft omkring 10.000 rækker pr. tabel. Det tal står ikke i den officielle dokumentation, men det er værd at regne med, hvis du planlægger et stort katalog.

Det, der oftest går galt, er ikke teknikken, men arbejdsdelingen. En dynamisk side har ingen sideeditor, så en marketingmedarbejder kan ikke flytte en sektion eller tilføje et afsnit uden at gå ind i skabelonen. Bygger du tabellen med få og brede tekstkolonner, ender indholdet med at være HTML skrevet i en celle, og så er du tilbage ved at redigere kode for at rette et komma. Bygger du den med mange små, veldefinerede kolonner, gør skabelonen arbejdet, og redaktøren skal kun forholde sig til data. Den beslutning træffes i uge ét og er dyr at lave om i uge tolv.

Vi bygger dynamiske sider i HubSpot fra bunden: datamodellen i HubDB eller på CRM-objektet, skabelonen i Design Manager, SEO-felterne pr. række og en struktur, jeres eget team kan udvide uden en udvikler. Skal I i gang med et produktkatalog, en forhandleroversigt eller en vidensbank, så lad os se på datasættet og give jer et realistisk estimat, før I opgraderer til Content Hub Professional.

Hvad danske B2B-teams bruger dynamiske sider til

Mønstret er det samme på tværs af brancher. Der findes et datasæt, som nogen allerede vedligeholder i et regneark, og som burde stå på websitet, men ingen gider lægge det ind som 60 enkeltsider. HubSpot fremhæver selv medarbejderoversigter, eventkalendere og produktkataloger som typiske eksempler. I danske B2B-portaler ser vi især disse syv.

Produkt- og varekatalog
Hvert produkt får sin egen URL med specifikationer, datablad og en formular. Tabellen får en kolonne pr. specifikation, så skabelonen kan bygge en ensartet specifikationstabel, uden at nogen formaterer noget i hånden. En dansk komponentleverandør med 400 varenumre får 400 landingssider, der kan rangere på varenavn og norm, uden at have en webshop. Ligger produkterne allerede som Products i CRM'et, kan de drive siderne direkte, så pris og status kun vedligeholdes ét sted.

Forhandler- og lokationssider
Et katalog over forhandlere, servicepartnere eller egne afdelinger med adresse, kontaktperson og åbningstider. Sider som /service/aarhus og /service/odense kan rangere lokalt, og de er langt nemmere at holde opdaterede end statiske sider. En landsdækkende installatør med 12 afdelinger får 12 sider, der reelt bliver vedligeholdt, fordi opdateringen er at rette en celle.

Integrationsoversigt
SaaS-virksomheder bygger typisk /integrationer som oversigt og derefter en side pr. integration med skærmbillede, datafelter og opsætningsguide. Det rammer søgninger som "produktnavn e-conomic" eller "produktnavn Business Central", og det er præcis den slags forespørgsler, der kommer fra nogen med et konkret købsbehov. Tabellen kan samtidig drive et filter på kategori, så oversigten er brugbar i stedet for at blive en endeløs liste.

Kursus- og eventkalender
Hvert kursus får en side med dato, sted, underviser og tilmeldingsformular, og oversigtssiden filtrerer på kommende datoer. En dansk uddannelsesudbyder kan køre hele efterårsprogrammet fra én tabel og lade et kursus falde ud af oversigten automatisk, når datoen er passeret, ved at filtrere rækkerne i skabelonen.

Ordbøger og vidensbanker
Ordbogssider er et af de reneste eksempler, fordi strukturen er identisk fra term til term. Siden her er selv en dynamisk side: opslagsordet, afsnittene og de relaterede termer ligger i HubDB, og skabelonen gør resten. Det er også derfor, vi kan tilføje en ny term uden at røre en eneste skabelonfil.

Case- og referencebibliotek
Kundecases med branche, løsning og resultat i hver sin kolonne, så oversigten kan filtreres på branche. For en dansk B2B-sælger er forskellen mellem "vi har cases" og "her er tre cases fra din branche" den, der flytter et møde. Filtreringen kræver dog, at branchen er sin egen kolonne og ikke bare et ord inde i en brødtekst.

Jobopslag
Stillinger med afdeling, lokation og ansøgningsfrist, hvor skabelonen kan lægge JobPosting-markup på. Det er en lille ting. Til gengæld forsvinder opslagene ellers ofte ud i et eksternt rekrutteringssystem, hvor de ikke bidrager til jeres eget domæne.

Fællesnævneren er, at data allerede findes, og at sidernes struktur gentager sig. Passer begge dele, er en dynamisk side næsten altid billigere end alternativet set over to år. Passer kun det ene, for eksempel fordi hver side skal se forskellig ud, er I bedre tjent med almindelige sider og et gennemarbejdet sæt moduler.

Alternativer, priser og begrænsninger

Alle moderne CMS'er kan generere sider fra en datakilde. Forskellen ligger i, hvor data bor, og hvem der skal vedligeholde dem. Her er de fire alternativer, danske B2B-virksomheder realistisk står med.

Webflow
Webflows CMS Collections gør det samme: en collection svarer til en tabel, og hvert item får sin egen side. Den visuelle editor er stærkere end HubSpots, og designere kan arbejde uden en udvikler ved siden af sig. Efter prisomlægningen i maj 2026 koster Premium-planen, der samler de tidligere CMS- og Business-planer, 25 USD om måneden ved årlig betaling og 39 USD ved månedlig, med 40 collections og op til 20.000 items ifølge Webflows egen prisoversigt. Svagheden er, at Webflow ikke kender jeres CRM. Skal en produktside vise en pris, der også står på et tilbud, skal den synkroniseres ind.

WordPress med Advanced Custom Fields
Custom post types plus ACF giver den samme struktur, og økosystemet er stort nok til, at der findes et plugin til næsten alt. ACF PRO koster pr. september 2026 49 USD om året for ét website, 149 USD for ti og 249 USD for ubegrænset ifølge prissiden for ACF PRO. WordPress selv er gratis, men hosting, opdateringer og sikkerhed er jeres ansvar, og det er der, regningen reelt ligger. Til gengæld er der ingen platformsgrænse på antal sider.

Headless CMS som Contentful
Data ligger i en API-first tjeneste, og frontenden bygges separat i for eksempel Next.js. Det giver fuld kontrol over performance og markup, og det samme indhold kan udstilles i app, website og kundeportal. Contentfuls Lite-plan står pr. september 2026 til 300 USD om måneden med 20 brugere og 1 mio. API-kald, mens gratisplanen giver 10 brugere og 100.000 kald. Det er den dyreste vej i udvikling, og I mister sideeditoren helt, så marketing kan ikke selv lave en landingsside.

Almindelige HubSpot-sider
Det oversete alternativ er at lade være. Har I 12 sider, der hver skal se forskellig ud, er 12 almindelige sider bygget på et godt modulbibliotek hurtigere at lave og lettere at ændre end en tabel plus en skabelon. Grænsen ligger erfaringsmæssigt omkring 20 til 30 sider med ensartet struktur. Under det tjener opsætningen sig sjældent hjem.

HubSpot vinder ét sted, og det er ikke på design. Det vinder, når de samme data skal bruges af marketing, salg og service på én gang. Ligger produkterne som CRM-objekter, driver de både produktsiderne, line items på tilbud og rapporterne, og ingen skal synkronisere noget mellem to systemer. Formularer, smart content og attribution virker på siderne fra dag ét, fordi de ligger inde i platformen i forvejen. HubSpot taber til gengæld på redaktørfrihed og på rå frontend-kontrol, og det taber klart på pris, hvis websitet er det eneste, I skal bruge platformen til.

Adgangen er til at gennemskue. Dynamiske sider kræver Content Hub Professional eller Enterprise, og hverken Free eller Starter har funktionen. Det fremgår af HubSpots vejledning til dynamiske sider, som også fastslår loftet på 10 dynamiske sider pr. datakilde.

Priserne skal læses med årstal på, fordi HubSpot ændrer pakketering ofte. Pr. september 2026 står Content Hub Professional på HubSpots prisside for Content Hub til 450 USD om måneden med tre Core Seats inkluderet og 3.000 credits, mens ekstra Core Seats koster 45 USD om måneden. Enterprise står til 1.500 USD om måneden med fem Core Seats, 5.000 credits og 75 USD pr. ekstra seat. Starter ligger på 20 USD pr. seat om måneden til listepris, og Free giver op til 30 sider med HubSpot-branding og ingen dynamiske sider.

Seat-modellen betyder i praksis, at prisen følger antallet af mennesker, der skal redigere, ikke antallet af sider. Det er en fordel, når I bygger 400 produktsider fra én tabel. Det er en ulempe, når ti personer hver skal rette to sider om måneden. Alle med et Core Seat kan redigere både HubDB-tabeller og sider, mens et View-only seat kun kan se dem.

De hårde grænser er værd at planlægge efter, før I bygger. Ti dynamiske sider pr. datakilde lyder rigeligt, men loftet rammes hurtigt, hvis I vil have en oversigt pr. sprog eller pr. brand på den samme tabel. Indekseringen dækker op til 10.000 records pr. sæt dynamiske sider og 50.000 indeksopdateringer om dagen pr. konto, hvilket betyder noget, hvis et helt katalog importeres på én gang. Serverless functions, som bruges til opslag mod eksterne systemer i realtid, findes kun på Enterprise.

Flersprogethed er den grænse, danske virksomheder oftest løber ind i. Skal kataloget findes på dansk, engelsk og tysk, skal I enten have en sprogkolonne og filtrere i skabelonen eller et sæt sider pr. sprog, og begge dele spiser af de ti. Ubegrænset antal sprog på flersproget indhold er desuden forbeholdt Enterprise.

På datasiden er billedet fornuftigt for en dansk virksomhed. HubSpot hoster kundedata i USA øst og vest, Canada, Australien og EU med datacenter i Tyskland, og konti på Starter, Professional eller Enterprise kan vælge datacenter, mens gratiskonti skal opgradere først. Det fremgår af HubSpots FAQ om cloud-infrastruktur og datahosting. Vælges EU, ligger HubDB-indholdet der også, og det er typisk den afklaring, en dansk databehandleraftale beder om.

Selve indholdet på en dynamisk side er offentligt og rummer sjældent personoplysninger, så GDPR-diskussionen handler i praksis om noget andet: formularerne på siderne og cookie-samtykket. Bygger I 400 produktsider med en formular på hver, har I 400 indgange til CRM'et, og samtykketeksten skal være ens på dem alle. Det er et godt argument for at lægge den i skabelonen frem for i en tabelcelle, hvor den før eller siden bliver rettet ét sted og glemt 399 andre.

Det kan ikke betale sig i tre situationer. Har I under 20 sider med ens struktur, er almindelige sider hurtigere. Skal hver side se markant forskellig ud, arbejder I imod skabelonen hele vejen. Og er websitet det eneste, I skal bruge HubSpot til, er 450 USD om måneden dyrt for en funktion, Webflow leverer for 25. Bruger I allerede HubSpot til marketing og salg, vender regnestykket, fordi I så ikke betaler for endnu et website-abonnement, og fordi data kun vedligeholdes ét sted.

Vi bygger typisk den første tabel og skabelon sammen med kunden og lader teamet selv tilføje rækker bagefter. Det er den billigste model, fordi udviklingstimerne ligger i skabelonen og ikke i indholdet. Vil I se, hvordan det hænger sammen med resten af platformen, ligger vores samlede gennemgang af HubSpot som platform et niveau over denne side.