---
title: How to create a HubSpot website with AI
description: "The complete HubSpot website workflow with AI, in eight milestones: positioning, site structure, copy-first wireframes, branding and the design ceiling, design, building the theme with a local pixel loop, setting up HubSpot and populating content, launch and after. Plus when Elevate or a landing page import is enough."
---

[Skip to content](https://themespot.app/blog/create-a-hubspot-website-with-ai#main-content)

[![themespot](https://themespot.app/hubfs/themespot-1.svg)](https://themespot.app/)

- Product
  
    - [Build themes/theme-development](https://themespot.app/theme-development)
    - [Manage content/content-management](https://themespot.app/content-management)
    - [Roadmap/roadmap](https://themespot.app/roadmap)
- [Pricing](https://themespot.app/pricing)

[Connect your portal](https://themespot.app/join-the-waitlist)

[← All posts](https://themespot.app/blog)

# How to create a HubSpot website with AI

By [Reece Sim](https://themespot.app/blog/author/reece-sim)·October 8, 2026·26 min read

AI is very good at writing code and very bad at turning your vibes into a HubSpot website your marketing team can run. I have spent six years building HubSpot sites and the last year getting agents to do it properly. This is the whole job, from the positioning workshop to the week after launch, written for the person who owns the outcome and may never open the design manager.

It is organised as eight milestones rather than a list of steps, because that is how the work actually lands. Each milestone has a deliverable you can hold, a gate where a human decides, and a note on where AI does the work and where it does not. Each one ends with a further-reading link for the deeper version.

## What you are actually building

A HubSpot website is two things, and most people only plan for one.

The first is the **theme**: the templates, sections, modules, fields and theme settings that HubSpot's page editor understands. A marketer drags a section onto a page, edits the headline in a field, swaps an image, publishes. The theme is the Lego.

The second is the **HubSpot configuration**: the active theme and its settings, the domain, the navigation, the global header and footer content, the forms and their CRM mapping, the blog and its templates, redirects, consent, tracking, integrations, the system pages. None of that lives in the theme. All of it has to be done before the site works.

A developer's job is both. An AI's job is both. If you plan only for the theme, you launch with a beautiful home page, a form that goes nowhere and a blog on the wrong template.

There is also a third thing, which I will keep coming back to because it is where AI projects quietly fail: **content population**. A theme ships one default set of content per module. Every real page, with its own headline and its own proof, is populated in HubSpot after the theme exists. That is separate work, with its own milestone.

## The on-ramps HubSpot gives you

Before you build anything, know what HubSpot already provides, because for some sites it is the right answer and for most sites it is the right place to start learning.

**Elevate, the default theme.** Available in every account. React-based modules, a solid set of sections and templates, and theme-setting presets that keep edits inside your brand. If you need a site this month and HubSpot-shaped is acceptable, Elevate is a good first site. It teaches your team the editor, the section library and theme settings, all of which carry over to a custom theme later. What it cannot do is be your brand. The presets are HubSpot's taste with your colours on top, and you cannot fetch Elevate from your portal and modify it the way you can the older default themes. The source is public on GitHub if a developer wants to fork it, at which point you own a large codebase you did not write.

**Landing page import, including the Claude Design publish action.** Claude Design, and a growing number of tools, can push a self-contained HTML page straight into HubSpot as a landing page. HubSpot wraps it in a template, creates the page and hands you an editor link, and re-importing the same design updates the page in place. This is a genuinely good on-ramp for a standalone page: a webinar sign-up, an event, a one-off offer, a quick test of a message.

It is not how you grow a website. Each import gets its own template, so there is no shared header, footer or theme settings. The content is baked into the import, so a marketer cannot drag the sections around or reuse a band on the next page. Build ten of them and you have ten unrelated templates. Use it for the thing it is for, and when you find yourself wanting the third one to match the first two, that is the signal to build a theme.

**The AI website builder.** HubSpot's own generator picks a template and fills it. Fine for a first site on a free portal, and a fast way to see your copy on a page. The moment you want a layout it does not have, you need a theme.

The rest of this article is the theme route: your positioning, your structure, your design, editable by your team for years.

---

## Milestone 1: Positioning and strategy

**Deliverable:** a brief that every later milestone reads.  
**Gate:** you sign it off before anyone draws a box.

The cheapest mistake to fix is the one you make in a text document. The most expensive is the one you discover when the designer has finished the home page. So the first milestone is a positioning workshop, and its output is a brief, not a sitemap or a mood board.

The workshop covers:

- **Ideal customer profile.** The two or three people who actually visit. Job title, company shape, what they are trying to find out, what they are afraid of, what they have tried already.
- **Jobs to be done.** For each person, the job they are hiring you for, in their words. Not "marketing automation", but "stop losing leads between the form and the sales call".
- **Journey stages.** What each person needs to see when they are unaware, when they are comparing, when they are deciding, and when they are already a customer. This is the axis the sitemap is built on later.
- **Proof inventory.** Every case study, logo, number, review, award and credential you actually have, with whether you are allowed to use it. AI will invent proof if you do not give it the real list. This list is the only thing that stops it.
- **Competitors.** Who they compare you to, what those sites say, and what you will say differently.
- **Messaging hierarchy.** The one sentence, the three supporting claims, the proof under each. Everything on the site descends from this.
- **What HubSpot needs to know.** Which form fills create what in the CRM, which properties they set, who gets notified, which lifecycle stage changes. The website is a CRM input, and this is the moment to say what the input is.
- **What already exists.** Current pages, their traffic and their conversions, so you know what to keep, merge, redirect or kill.

**Where AI does the work.** Claude is a good interviewer if you ask it to be one. "Interview me for a website positioning brief, one question at a time, recommend an answer for each, and write the brief when you have enough" gets you most of the way in an hour. It is also good at reading your existing site, your competitors' sites and your last twenty sales call transcripts and telling you what the market actually says. It is bad at knowing which claims are true. You supply the truth, it supplies the structure.

**Where it does not.** Deciding. The brief contains choices, who you are for and who you are not, and a model will happily write both versions. Someone with authority picks.

*Further reading: Running a positioning workshop for a website, with the interview script.*

## Milestone 2: Site structure

**Deliverable:** a sitemap with a template and a primary action for every page.  
**Gate:** the template count is agreed before design starts.

The sitemap comes from the brief, not from the old site. For each persona and each journey stage, what content category do they need? That gives you the areas of the site. Then the pages inside each area, each with one primary action.

A normal B2B site ends up with:

- Home
- One page per service, product or audience, depending on how the brief segments the market
- A proof area: case studies, customers, results
- About, and team if the people matter to the sale
- Pricing, if you publish it
- Contact, demo, or whatever the primary action is
- Blog listing and post
- Landing page layouts for campaigns, without the main navigation
- The system pages nobody plans for: 404, search results, subscription preferences, password prompt, unsubscribe

**The rule people get wrong: templates.** A normal site needs four or five page templates, not twenty. Home. A flexible inner page. A landing page without navigation. Blog listing. Blog post. Every other page is the inner template with different sections on it. People over-template because it feels safer to give the editor a "services template" and a "case study template", and six months later nobody can add a section to the services page without a developer because the template was rigid.

Fewer templates, more sections. The sitemap says which template each page uses, and that list becomes the theme's template list in Milestone 6. If you cannot build a page from one of those four or five, ask why before adding a sixth.

**Where AI does the work.** Given the brief and a crawl of the current site, it proposes the sitemap, maps old URLs to new ones (which becomes the redirect list in Milestone 8), and flags pages with traffic that the new structure drops. It is also good at the boring part: listing every system page HubSpot will need.

*Further reading: Sitemaps that survive the next three years: personas, journey stages and the four-template rule.*

## Milestone 3: Writing the content

**Deliverable:** a copywritten wireframe for every page.  
**Gate:** the copy is signed off before any page is designed.

This is the milestone that gets skipped, and it is the reason most websites feel like a template with words poured in. Build the design around the copy. Never the copy around the design. A hero that was designed with a 40-character headline slot forces you to write 40-character headlines forever.

The process:

1. **Wireframe each mapped page as a list of bands**, with a goal-led writing prompt under each band instead of placeholder text. Not "Hero: Lorem ipsum" but "Hero: what you do, in plain words, for the person in the brief." Then "Proof bar: client logo 1, client logo 2, client logo 3." Then "Pain: agitate the problem the prospect is feeling right now." Then "Ideal: show the scenario after they fix it." Then "How it works: three steps, each one sentence." Then "Proof: the case study that matches this persona." Then "Objections: the three questions they ask on every sales call." Then "Action: the one thing we want them to do."
2. **Hand the wireframes to a copywriter.** A human one, if you can. The prompts tell them what each band is for; their job is to make it land. They also decide what imagery each band needs, and they write that in, because a designer needs to know "this band has a product screenshot" before they can design it.
3. **Sign the copy off.** Then, and only then, design.

The band names matter more than they look. "Hero", "Proof bar", "Testimonials", "Pricing", "FAQ" are the names a marketer will see in the editor's section picker in Milestone 6. Use the words they would use. Nobody says "prose" and nobody says "SocialProofGrid".

The wireframes also tell you how many **distinct** bands the site needs. Eighty pages usually need fifteen to twenty band types. That number is your module list, and it is the single best predictor of how long the build takes.

**Where AI does the work.** First drafts, from the brief and the proof inventory, in your brand voice. Rewrites to length. Variants for each persona. Reading your sales call transcripts for the exact objections customers raise. It is a very good junior copywriter with perfect recall of the brief. It is a poor senior one, and it will invent a case study if the proof inventory is thin.

**Where it does not.** The final pass. If you cannot afford a copywriter, at least have the person who knows the customers best read every headline out loud.

*Further reading: Copy-first wireframes: the band prompts I use, and how to brief a copywriter from them.*

## Milestone 4: Branding and visual style

**Deliverable:** a brand file every downstream tool reads.  
**Gate:** the design ceiling is agreed before pages are designed.

If a brand exists, extract it. Logos and their variations, placement rules, the colour palette, type, spacing, iconography, photography style, accent shapes, watermarks, motion. Write it down as tokens in one file: a `design.md`, a brand kit, whatever your tools read. The point is that the design tool, the theme builder and the content agent all read the same file, because if the AI has to guess the brand it guesses differently every time.

Then the conversation most brand guidelines never have: **the design ceiling**. A brand built for a logo and a letterhead often has one primary colour, one typeface and a rule that says "never put text on a photo". That brand will produce a flat website, and no amount of layout skill fixes it. Before you design, decide:

- Is there more than one primary colour, or at least a strong secondary that can carry a whole section?
- What accent shapes, patterns, gradients or watermarks give sections texture without content?
- Which logo variations exist (mark only, horizontal, reversed) and where each may be used?
- How much motion is allowed, and where?
- What does an image look like when there is no photo for a band? Illustration, abstract, product, nothing?
- Is the type scale wide enough for a hero headline and a footer legal line?

If the answers are "one colour, one weight, no shapes, no motion", say so now and lower expectations, or extend the brand now and get it signed off. Discovering the ceiling in the design review is the expensive version.

If no brand exists, this is where you look at three sites you admire and decide what you are taking from each, then tokenise that.

**Where AI does the work.** Extraction from an existing site, logo files or a PDF guideline into tokens. Generating several visual directions from the brief for a human to pick between. Proposing the extensions, a secondary palette, an accent shape language, that lift the ceiling while staying recognisably the same brand. Writing the brand file in the shape the next tools need.

*Further reading: The design ceiling: why brand guidelines made for print produce flat websites, and what to add.*

## Milestone 5: Designing the pages

**Deliverable:** a pixel reference for every template, desktop and phone, with the real copy in it.  
**Gate:** design sign-off, page by page, against the copy.

Now the pages. With a signed brief, a sitemap, copywritten wireframes and a brand file, a designer has everything they need and nothing to invent. We recommend hiring a great designer. You can also let Claude Design rip, or use whatever design tool you prefer. The inputs are the same either way: the wireframe for the page, the copy for the page, the brand file, and the instruction that the job is layout and polish, not content.

Design every distinct template and every band at least once. The home page and one inner page usually cover most bands. Then the landing page without navigation, the blog listing, a blog post, and the system pages at least once. Desktop and phone for each.

What you get now is usually an **interactive mock-up**. Designers hand these over routinely since AI can write front-end code so easily: a working HTML page, or a small React app, that looks exactly right. It is a wonderful artefact. It is also not the right shape for HubSpot, and that is the whole of the next milestone. Treat it as the pixel reference it is: the picture of what "done" looks like, that the build will be compared against.

**Where AI does the work.** The design itself, if you go that route. Phone variants from the desktop design. Image generation for the bands the copywriter marked as needing abstract imagery. Checking the design against the brand file.

**Where it does not.** Taste, and restraint. A model given eight bands will make eight hero sections. A designer makes one hero and seven quiet bands that let it breathe.

*Further reading: Designing a HubSpot site with Claude Design: inputs, guardrails and what to export.*

## Milestone 6: Building the theme

**Deliverable:** a theme in your portal that matches the design and that a marketer can edit.  
**Gate:** local pixel check passed, then upload to a new folder with your agreement.

This is the milestone the word "developer" used to mean. It has five parts.

### 6.1 Plan the theme before building it

An agent, or a developer, reads the design and the wireframes and writes a plan you agree to. The plan answers:

- **Which bands are the same band.** The testimonials on the home page and the testimonials on the service page are one section, not two. The plan lists every distinct section and which pages use it.
- **Which modules make sense.** A section is made of modules. The plan says, for each section, what the content module is and what it holds: the hero holds a headline, a subhead, an image and two buttons; the feature grid holds a repeater of features, each with an icon, a title and a sentence.
- **How dynamic content will be handled.** A blog listing reads posts. A team page might read a HubDB table. A case-study area might read custom objects. A pricing table might be hard content. The plan says which, because it changes what gets built.
- **What HubSpot provides natively.** Forms, navigation menus, the logo, CTAs, the blog templates, site search, the language switcher. These are placed, not rebuilt.
- **What is editable and what is fixed.** Every heading, paragraph, image, link, button and repeated item is a field. Decorative shapes, layout and spacing are CSS. Not everything is a field. Only content is.

This is **component-based design**, and it is worth explaining to anyone who has not built software. A page is not drawn; it is assembled from parts. Each part has a shape (its fields) and one default appearance (its default content). The same part is used on many pages with different content. Change the part, every page changes. That is why "add a logo to the proof bar" is a one-minute job on a well-built theme and a half-day job on a badly built one, and why the plan matters more than the code.

### 6.2 Scaffold a starting point and set the rules

Scaffold from HubSpot's CMS theme boilerplate: a base layout, templates, header and footer as global partials, example modules, a theme settings file. Every HubSpot default theme is built on it and it already handles the parts you would get wrong.

Then write the rules the AI has to follow, in the file your agent reads first. The ones that have saved real builds:

- **Read HubSpot's current documentation for anything platform-specific. Never work from memory.** A model's HubSpot knowledge is a blend of several years of docs, and roughly a third of what it writes from memory fails HubSpot's validator.
- **Use what HubSpot provides natively.** Never rebuild a form, a menu, a CTA or a blog listing as fields.
- **Reuse before create.** Clone the nearest existing section or module. Forty one-off modules is a failed build even if every one of them renders.
- **Every piece of content is a field, and every default is real content** from the copywritten wireframe. No "Enter heading here".
- **Names are the editor's words.** The section picker in HubSpot is a marketer's tool. "Testimonials", not "SocialProofGrid".
- **Colours, fonts and spacing come from theme settings**, never hard-coded in a module.
- **Never paste the design's HTML into one rich-text module.** This is the shortcut every model takes when it is not told otherwise. It looks right in a screenshot and is wrong in every way that matters: nobody can edit a word, theme settings do nothing, forms and menus are not wired in, and the next page has to be pasted again.

### 6.3 Convert the design into something HubSpot-shaped

The thing a non-developer most needs to understand about this part: **the design is the pixel reference, and the code will be different.** The theme is rebuilt from the design, whether the input is an interactive mock-up, an HTML export or a screenshot. Nothing is pasted. The mapping is:

- **Tokens become theme settings.** The brand file's colours, fonts, content width and spacing go into the theme's settings, so they appear in the editor and flow into every module. Change the brand colour once; every page follows.
- **Each band becomes a section**: a preset a marketer drops onto a page.
- **Each kind of content becomes a module** with fields. Repeated items, cards, logos, FAQ entries, are one module with a repeater, not copies.
- **Each page layout becomes a template** with a drag-and-drop area that includes its sections by default, so a new page from the template already reads as finished.
- **Header and footer become global partials**, edited once for the whole site, with HubSpot's menu module holding the navigation.

And the part people miss: **content does not map blindly to fields.** A module has one default set of field values. The home page hero's default is the home page hero copy. The service page hero is the same module with different content, and that content is populated in HubSpot, in Milestone 7, not in the theme build. The theme build produces the parts and one demonstration of each. The site is populated afterwards. If you expect the theme upload to produce your finished site, you will be disappointed at exactly the moment you can least afford it.

This is the step the free plugin, **Theme Dev Tools for HubSpot**, exists for. In Claude Code:

```
claude plugin marketplace add reecesim/theme-devtools-for-hubspot
```

Then, in a folder with your design in it:

> turn the design in ./design into a HubSpot theme

It runs the pre-flight (what the machine has, what is missing, nothing installed without asking), reads the design as a reference, shows you the plan from 6.1 and waits for your agreement, then builds the theme from HubSpot's boilerplate with every piece of content as a field and the design's own copy as the defaults. The HubL guidance inside it is six years of mistakes written down as rules, including the ones HubSpot only tells you about at upload.

### 6.4 Verify locally, before HubSpot ever sees it

This is the part that makes AI usable for theme work at all. The reason models are so good at writing code and so bad at producing HubSpot-deployable themes is that they cannot verify their own work. HubSpot's own local preview renders modules without the theme's styling, needs a signed-in account to preview templates, and signing an agent into your portal just so it can look at a module is a terrible trade. So the model guesses, you look, you describe what is wrong, and you have become the test harness.

The plugin bundles a renderer that draws the whole theme on your machine with no HubSpot login: templates and modules in context, fully styled, with the real defaults. Then the pixel contract: full-page screenshots of the design and the build at 1440×900 and 390×844, compared, the biggest difference fixed first, repeated until the two match or every remaining difference is explained from its crop. Up to eight rounds, and the agent does the looping.

I used this to clone the Linear pricing page into HubSpot, pixel for pixel, from one prompt. What it does not do: it renders HubL as a close approximation and HubSpot's render is the authority; it uses the theme's defaults, not your real pages; it ships classic HubL themes only, not CMS React. React themes are the hosted product, covered in Milestone 7.

### 6.5 Upload

With the theme passing locally, upload it with HubSpot's own CLI, to a **new folder** in the design manager, only with your agreement. Nothing on the site changes.

If you already have a live HubSpot site, be careful here. Uploading over the top of the existing theme can conflict with pages that use it, and global content that was baked in on the old theme's first upload does not update when you upload again. Put the new theme beside the old one. If your subscription includes HubSpot's content staging tool, use it: stage the new pages against the new theme, review them, and publish the lot at once.

HubSpot runs its validator on upload. Reserved field names, image defaults that point at paths, a HubDB field with no table set. The local check catches most of these; fix what HubSpot still rejects and upload again. The theme now exists in your portal, and nothing is live.

*Further reading: From a vibe-coded mock-up to a HubSpot theme: the plan, the rules, the pixel loop.*

## Milestone 7: Setting up HubSpot

**Deliverable:** a configured portal with populated pages, working forms and a blog on the right templates.  
**Gate:** every page reviewed as a draft; nothing published yet.

The second half of the job, and the one nobody budgets for. Everything here is a setting or a piece of content in HubSpot, not a file in the theme, which is why "I built the theme" and "the site works" are two different sentences.

### 7.1 Theme settings and brand kit

Set the theme active under Website pages and open Theme settings. Check the tokens landed: colours, fonts, spacing, buttons. Set the logo and favicon. Then add the same colours and fonts to HubSpot's brand kit, so the editor's colour picker offers the brand instead of a rainbow.

### 7.2 Global header and footer, and menus

Open any page, click into the header, and fill the global content: logo, navigation, footer columns, social links, the legal line. This content exists once and is shared by every page. Build the primary and footer menus under Navigation; the theme's menu module reads them. The internal links will point at pages that do not exist yet, so plan to come back after population.

A lesson from a SaaS client's build: the theme shipped with default links to `/about`, `/contact` and `/blog` in a dozen places, and the portal's real pages were `/about-us`, `/contact-us` and a blog at a different path. Every default link was a 404 on launch day. Every link a theme ships as a default is an address on every page built from it. Look up the real addresses before you set them, and audit links before you publish.

### 7.3 Domains, system pages, consent and tracking

Connect the domain and set the primary for website pages, blog and landing pages. Assign the theme's 404, search results, subscription preferences and password prompt templates under System pages. Under Privacy and consent, enable the cookie banner for the regions you need; the theme does not do this, HubSpot does. Decide how tracking is loaded: HubSpot's own script, a tag manager container, or both, and make sure consent gates them. Connect the integrations the brief named: chat, scheduling, analytics, the CRM sync if HubSpot is not the system of record.

### 7.4 Content population

Now the pages. Create each page in the sitemap from its template. Because the templates ship with their sections included and the fields defaulted to the demonstration copy, a new page is most of the way there on creation. The work is the page-specific content from Milestone 3: this service page's headline, its proof, its FAQ.

The honest way to do this without tooling is by hand: paste from the copywritten wireframe into the editor's fields, page by page. It is free and fine for a ten-page site. For forty pages it is a week.

This is where the hosted ThemeSpot workspace plugs in. Connected to the portal through a HubSpot app, so no personal access key is handed to an agent, it reads the sitemap and the copy, creates each page from the right template, populates every field, and queues the results as drafts. "Create the five service pages from the copy document" is one instruction. You review each draft in the normal HubSpot editor and approve it. Nothing goes live until a named person says so.

Then set each page's SEO title, meta description and featured image, and come back to the navigation menus now that the pages exist.

### 7.5 Forms

Forms live in HubSpot's forms tool. The theme's form module places them.

- Create one form per **intent**, not one per page: contact, demo, newsletter, download. The same form goes everywhere that intent appears.
- Map every field to a CRM property, and create the property first if it does not exist. This is the moment the brief's "what HubSpot needs to know" becomes real.
- Set what happens on submit: the thank-you message or page, the notification, the lifecycle stage change, the list it joins, the workflow it triggers.
- Place it by choosing it in the form module's field. The theme styles it.
- Submit one test entry per form and check it arrived with the right properties.

### 7.6 Blog

Also configuration, also forgotten.

- Create the blog under Website. Name, URL slug, primary domain.
- Assign the theme's **listing** template and **post** template. Without this the blog renders on HubSpot's default and nobody notices until the first post.
- Create the authors with real photos and bios, and the tag taxonomy from the brief. Five to eight tags, not forty.
- Set the listing's title, description and posts per page. Turn on RSS and the subscription form if you want digests.
- Design the post template for the worst post, not the average one: long, with images, a table, a code block and an embedded video. Most themes ship a post template that only handles short prose.
- Draft the first three posts. The first real post is the proof the templates work.

### 7.7 Dynamic content and personalisation

If the plan in 6.1 said a team page reads a HubDB table, or a case-study area reads custom objects, this is where the data goes in and the dynamic pages are set up: the table or object, the template bound to it, the page that lists and the page that details. The same for personalisation: smart content rules, membership-gated pages, the language variants if the site is multilingual. None of this is in the theme either. It is configured here, against the theme's templates.

**Where AI does the work.** Population, SEO fields, redirects, blog drafts, HubDB rows from a spreadsheet, and anything else that is "do this a hundred times from a document". The hosted workspace does these through an approval gate. The free plugin stops at the theme upload and does not touch pages, forms or settings.

**Where it does not.** The decisions that touch the CRM: which property a field maps to, which stage a form changes. Those are five minutes of a human's attention and a year of consequences.

*Further reading: Setting up HubSpot after the theme: the configuration checklist and the content population playbook.*

## Milestone 8: Launch, and life after launch

**Deliverable:** a live site with redirects in place, and a way to keep it alive.  
**Gate:** the pre-launch crawl is clean, forms tested, then the domain switch.

### Before the switch

- **Crawl every page** for broken links, missing alt text, missing meta descriptions, heading order, image weight and colour contrast. The hosted workspace runs this as Site Health and drafts each fix for approval. Otherwise, a crawler and a checklist.
- **Redirects, in bulk.** Every URL from the old site maps to a new one, from the list made in Milestone 2. Launch without this and you throw away the rankings you had.
- **Walk every template on a phone.** The pixel loop checked the design at 390 wide, but it checked the design, not your content. A real headline is longer.
- **Test every form again**, with the cookie banner showing and consent declined, then accepted. Check tracking fires only when it should.
- **Publish the pages, switch the primary domain**, check the live site in a private window, and then check the old URLs redirect.

### After the switch

The theme is built once. Content changes every week, and this is where an agent that knows the site earns its keep. "Update the pricing everywhere it appears." "Add the new case study to the three pages that mention that industry." "The CTO's title changed." The hosted workspace does this in a marketer mode: the agent can edit content, drafts first, with approval, and can never touch theme code. Because it reads the portal, it knows which pages exist, what template each uses and what is on them, so "everywhere it appears" means everywhere.

Re-run the crawl monthly. Add a section to the theme when the marketing team asks for the same custom HTML twice. Keep the brief current, because in a year someone will redesign a page and the brief is the only thing that stops them inventing a new positioning.

*Further reading: The pre-launch gate for a HubSpot site, and the monthly loop that keeps it healthy.*

---

## Where the tools fit

- **Milestones 1 to 5** are any good model in a chat window plus the right humans, with your documents as the inputs. The craft is in the documents.
- **Milestone 6** is the free plugin, **Theme Dev Tools for HubSpot**: the plan, the rules, the conversion, the local render, the pixel loop, the upload. No account, no telemetry, nothing phones home.
- **Milestones 7 and 8** are HubSpot configuration and content. The hosted workspace at themespot.app does them through an approval gate, with a HubSpot app connecting the portal so the agent never holds a personal access key. It also builds React themes on a maintained component library, for teams that want that route, with the same local render and pixel loop. It has a free tier, and the plugin stays free regardless. The plugin points you at the hosted product only where it truthfully cannot do what you asked; if you never hit that wall, you never need it.

## The short version

- A HubSpot website is a theme plus the HubSpot configuration plus populated content. Plan for all three.
- Elevate and landing page imports are good on-ramps. When the third page needs to match the first two, build a theme.
- Positioning brief, then sitemap, then copywritten wireframes, then brand file, then design. Each milestone is a document the next one reads.
- The design is a pixel reference. The theme is rebuilt from it as sections, modules, fields and theme settings, and verified locally against it before upload.
- A theme ships one default per module. Everything else is populated in HubSpot afterwards.
- Configure HubSpot: theme settings, global content, menus, domains, system pages, consent, tracking, forms, blog, dynamic content.
- Crawl, redirect, test, switch. Then let an agent manage content with approvals.

Install the plugin, point it at a design, and look at what comes back. Then tell me where it is wrong. That is how it got this far.

*HubSpot is a trademark of HubSpot, Inc. ThemeSpot is not affiliated with or endorsed by HubSpot.*

![](https://themespot.app/hs-fs/hubfs/fsdf%20(1).png?width=64&height=64&name=fsdf%20(1).png)

Written by

Reece Sim

[More from this author →](https://themespot.app/blog/author/reece-sim)

[← Back to all posts](https://themespot.app/blog)

[![themespot](https://themespot.app/hubfs/themespot-1.svg)](https://themespot.app/)

Runs alongside HubSpot. Never replaces it.

Your site is yours, forever. ThemeSpot is the bonus.

All systems normal

- Legal
  
    - [Privacy](https://themespot.app/privacy)
    - [Terms](https://themespot.app/terms)

© 2026 ThemeSpot

HubSpot is a trademark of HubSpot, Inc. ThemeSpot is not affiliated with or endorsed by HubSpot.

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Reece Sim",
    "url" : "https://themespot.app/blog/author/reece-sim"
  },
  "dateModified" : "2026-10-08T02:22:31.894Z",
  "datePublished" : "2026-10-08T02:22:31.000Z",
  "headline" : "How to create a HubSpot website with AI",
  "mainEntityOfPage" : {
    "@id" : "https://themespot.app/blog/create-a-hubspot-website-with-ai",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "https://themespot.app/hubfs/themespot.svg"
    }
  }
}
```