HubSpot CMS is a marketing platform that hosts websites, and the parts that make it useful to a marketing team, the forms, the tracking and the consent banner, are the parts that most often cost points on this rubric. None of the three checks this post covers is rated Low effort, and all three are fixable from inside the platform. What follows describes documented default behaviour as of this writing; the developer documentation is the reference for anything you are about to build.
What HubSpot CMS does by default
Pages are built from themes, templates and modules, written in HubL, and rendered on HubSpot's servers, so by default the page an agent fetches contains the page's content, which is what check A7 measures. Confirm it with a fetch rather than take it from this post. A HubSpot-hosted page also carries the HubSpot tracking code by default, a form placed on a page is delivered by the forms module, and a cookie banner is a feature under the privacy and consent settings that you switch on rather than something present from the start.
Titles, descriptions and Open Graph fields are per-page settings, a sitemap is generated, and robots.txt is editable from the settings. The llms.txt guide covers the file A4 wants; check the current documentation for whether a plain text file can be served at the root of a HubSpot-hosted domain.
What it tends to get wrong
The cookie banner and check A6. A6 asks whether the rendered homepage is dominated by a challenge or consent interstitial. The scanner detects this from markup, looking for identifiers it knows: the markup of common consent managers, g-recaptcha and the reCAPTCHA script, hCaptcha, and a handful of challenge-page phrases. A page where the only marker is a cookie wall scores one point of two; a page with a CAPTCHA marker scores zero.
Two things follow. Whether your banner trips the check depends on whether its markup carries one of those identifiers, and the markers field in the A6 evidence tells you what was matched. And a homepage form with reCAPTCHA enabled puts the reCAPTCHA script into the rendered HTML, which the scanner records as a CAPTCHA marker whether or not it covers the page. HubSpot documents a spam-prevention option on forms; check the current documentation for whether it is on by default and what it loads. Cookie walls are interstitials explains why a consent dialog counts at all: an agent cannot click it.
Forms and check C1. C1 audits the forms in the raw HTML of the crawled pages. Every input needs an associated label, an aria-label or an aria-labelledby; inputs whose name suggests an email, phone or number field need the matching type; and each form needs a real submit control, a button with type="submit", a button with no type, or an input with type="submit". A site with no forms in its raw HTML scores three of five, by design: no forms is not a failure, but it is not evidence either.
That last rule is the one that matters here. If the form is built in the browser by a script, the scanner sees no form, awards three points, and the remaining two are unreachable until the form is in the document. HubSpot documents a script-based embed for placing forms on external sites; how a form placed through the forms module on a HubSpot CMS page is delivered is something to check by fetching the page and searching for <form. If it is there, read the labels and types. If it is not, the fix is below.
Structured data and check B1. A theme may or may not emit JSON-LD by default, and what it emits may not match the types check B2 wants for your site type. B1 wants a parseable application/ld+json block on the homepage and on half or more of the crawled pages; invalid JSON scores as if absent. Fetch the homepage and search for ld+json before assuming either way; the typesFound field under B2 lists what the crawler parsed.
The tracking script. Script weight is the thing people expect to be penalised, and it mostly is not: B5 has excluded the contents of script elements since rubric version 1.0.1. What the tracking layer costs is indirect. The cookies it sets are the reason the consent banner exists, and the banner is what A6 sees.
Fixes in order of effort
All three checks are rated Medium; take them in this order.
The banner and the analytics question
The clean answer to A6 is to have no consent interstitial, and the only honest way to have none is to set no non-essential cookies before consent. Whether HubSpot's tracking can run in a mode that does that is a question for the current privacy and consent documentation, which describes the banner's modes and what the tracking code does before consent in each. If such a mode exists, scan afterwards and read the A6 markers field to see whether the scanner still matched anything.
The alternative is cookieless analytics instead of the HubSpot tracking on the pages where attribution does not depend on the cookie. That is a business decision rather than a rubric one; the rubric only sees markup.
Whatever you decide, remove reCAPTCHA from any form on the homepage unless spam makes it unavoidable, because that is the marker that takes A6 from one to zero.
Forms in the document
If the form is not in the raw HTML, the fix is to put it there. HubSpot documents raw HTML forms that post to its forms API, and building the form as ordinary HTML in a custom module gives you full control of the markup. Whichever route you take, the markup the scanner wants looks like this:
<form action="/contact" method="post">
<label for="email">Work email</label>
<input id="email" name="email" type="email" required>
<label for="phone">Phone</label>
<input id="phone" name="phone" type="tel">
<button type="submit">Send</button>
</form>
Three details decide the score: a label whose for matches the input's id, since a placeholder is not a label; a type that matches the field, because the scanner reads the name and id and a field called email with type="text" counts as wrong; and a submit that is a button. Forms an agent can fill goes through each rule and the evidence fields, unlabelled, wrongTypes and realSubmit, that report them.
Structured data through templates
Do this once, in the template, not per page. The base template's head is where an Organization block belongs, with a sameAs array because D2 reads it too. Type-specific blocks belong in the template for the page type: Article or BlogPosting in the blog post template, filled from the post's fields, and FAQPage or Service on the pages that are honestly those things.
The trap is the one every template language has: a HubL variable inserted into a JSON string breaks the block the first time a title contains a double quote. HubL has filters for emitting a value as JSON; check the current documentation for the right one, use it on every inserted field, and validate the live output with a JSON parser. Structured data across templates covers the general approach, and JSON-LD that parses covers the ways it goes wrong.
What is not fixable without leaving the platform
If lead attribution depends on the HubSpot tracking cookie and the banner it requires, and no consent mode leaves the homepage free of consent markup, A6 stays at one point. That is a reasonable trade for a team whose pipeline reporting runs on that cookie; know that it is a trade and record it.
Anything served as a script-built widget with no HTML alternative, a chat window or a meetings embed, is invisible to an agent, and the only fix is a plain HTML version of the same thing. For forms, that route exists; for the others, decide whether an agent needs them.
Check your own site
Run the free scan and read three fields: markers under A6, forms under C1 and pagesWithInvalidJsonLd under B1. Between them they tell you which of the three sections above applies. The definitions are on the methodology page under discovery and access, understanding and actionability, and the implementation service is the option if you would rather hand the template work to someone.