HubSpot CMS for Marketers common mistakes
HubSpot CMS for Marketers · Understand the traps and how to avoid them.
Treating HubSpot's drag-and-drop page editor and the theme/template layer as interchangeable, so the candidate edits module fields in the page editor expecting changes to persist across every page built on that template.
HubSpot separates template-level defaults (set in the design manager or theme) from page-level overrides (set in the page editor). Candidates who learned on generic site builders assume edits in the editor are global, when page-level edits apply only to that page instance.
What to do instead
Learn the distinction explicitly: template and module defaults live in the design manager/theme files and cascade to new pages; page editor edits are instance-level overrides. When a question asks how to change a default for all future pages, the answer involves the template or module, not the page editor.
Confusing global content (global modules, global groups, partials) with reusable-but-editable modules, and choosing the wrong one when asked how to update a footer or navigation across the whole site from one place.
The terminology overlaps and the editor surfaces several 'reusable' options. Candidates pick the first reusable-sounding option without checking whether the change should propagate automatically or be editable per page.
What to do instead
Build a decision rule: global content updates everywhere automatically and cannot be edited per page; a saved module or partial is reused but can be overridden per instance. Map site-wide brand elements (footer, nav, announcement bar) to global content and repeated-but-varied blocks to regular modules.
Assuming a page is live the moment it is saved or published, without accounting for the draft/published state, scheduled publish time, or the difference between the page URL and the preview URL.
The editor autosaves drafts and shows a preview that looks identical to the live page. Candidates who test by refreshing a preview link conclude the page is public when it is still a draft or scheduled for later.
What to do instead
Memorize the lifecycle: draft, scheduled, published, and unpublished are distinct states. Verify by opening the live URL in a private window, and check the scheduling control and the page's status indicator rather than the preview pane. Questions about 'why can't visitors see it' usually hinge on state, not on template errors.
Mixing up HubSpot's template types (page templates, blog templates, system templates, email templates) and assigning a page template to blog content or vice versa when setting up a new content type.
The template picker lists many templates and the names are often similar. Candidates who have not built or assigned templates in the design manager guess based on the template's visual name rather than its type.
What to do instead
Learn which content type each template serves and where templates are assigned (page settings vs. blog settings vs. system settings for search, error, and password pages). When a question describes blog listing behavior, the relevant template is the blog template, not a standard page template.
Choosing a page's URL or editing it after publication without planning redirects, causing broken links and lost equity, and failing to recognize when a redirect rule is the correct answer.
URLs feel cosmetic during drafting, and the redirect tooling lives in a different area of settings. Candidates underestimate how often exam scenarios hinge on preserving old URLs.
What to do instead
Treat URL changes as migrations: update the slug, then add a redirect from the old path to the new one and verify it. Know that HubSpot supports URL redirects in settings and that changing a live page's slug without a redirect is the classic cause of 404s. Practice identifying the scenario that requires a redirect versus a canonical tag.
Treating SEO fields as a single setting, so the candidate cannot distinguish the page title (browser/H1-adjacent metadata), the meta description, the H1, and the URL slug, or assumes editing one changes the others.
HubSpot groups these fields in one SEO panel, and the visual editor may display a heading that is not the H1. Candidates skim the panel and assume the fields are linked.
What to do instead
Learn each field's job: title tag affects the SERP headline and browser tab, meta description affects the SERP snippet but not rankings directly, H1 is on-page structure, and the slug is the URL. Check the page's SEO panel field by field and confirm the H1 in the page body is separate from the title tag.
Confusing blog-level settings with individual post settings, such as assuming a change to the blog's default author, template, or comment settings applies retroactively to existing posts.
Blog settings are centralized, and it is intuitive to assume central settings govern everything. In practice, many post attributes are set per post at creation and inherited only for new posts.
What to do instead
Separate blog-wide configuration (listing template, default author, comment policy, RSS, subscription settings) from per-post fields (author, tags, meta description, featured image). When a question asks how to change an existing post's author or metadata, the answer is the individual post editor, not the blog settings page.
Treating topics/tags as free-form labels with no strategic role, so the candidate cannot answer questions about topic clusters, pillar pages, or how tagging affects blog listing and related-post behavior.
Tags look like simple metadata in the editor. Candidates who have not planned content around clusters miss that tags drive listing filters, related content, and topical authority signals.
What to do instead
Study the topic cluster model: a pillar page targets a broad term and cluster posts target subtopics, linked bidirectionally. Know that blog tags power filtered listing URLs and related-post modules, so consistent tagging is an architecture decision, not an afterthought.
Reading analytics at the wrong scope - comparing page-level analytics to site-wide traffic, or attributing blog views to landing pages - and then drawing conclusions from mismatched denominators.
HubSpot's analytics tools are organized by object (pages, blog, landing pages, sources) and each has its own filters and date ranges. Candidates grab the first number they see without checking the report's scope.
What to do instead
Before interpreting any metric, state the report's object, date range, and filters. Compare like with like: page views to page views, sessions to sessions. For attribution questions, use the sources report and confirm whether the metric is contacts, sessions, or submissions, since each answers a different question.
Assuming default analytics already answers a custom question, instead of recognizing when a custom report, funnel report, or event is required - and conversely, building a custom report when a built-in one suffices.
The reporting menu is large and the built-in reports are prominent. Candidates either over-trust defaults or over-engineer, because they have not mapped question types to report types.
What to do instead
Learn the mapping: traffic and conversion questions map to the traffic analytics and sources reports; multi-step journey questions map to funnel or attribution reports; cross-object questions (deals by campaign, contacts by source) map to custom report builder. Practice phrasing a question and naming the minimum tool that answers it.