Skip to content

Pages

HubSpot pages come in two varieties — site pages and landing pages. Despite being nearly identical in structure, they use different API endpoints and have subtle behavioral differences. JetStack AI captures the full page definition, including drag-and-drop layouts, widget configurations, and embedded assets, then reconstructs everything in the destination portal.

During import, JetStack AI retrieves the complete page definition:

  • Page metadata — name, slug, title, meta description, page type, subcategory, language, publish state
  • Template reference — the template path the page is built on
  • Content body — the raw HTML/HubL content of the page
  • DnD layout data — the full drag-and-drop layout structure (layout sections, rows, columns, widgets)
  • Widget configuration — all widget/module parameters including form IDs, HubDB table IDs, CTA references, and custom module settings
  • Featured image — the page’s featured/social sharing image URL
  • Domain configuration — which domain the page is published on

JetStack AI determines the page type using two fields from the HubSpot API:

FieldSite Page ValueLanding Page Value
pageTypesite-pagelanding-page
subcategorysite_pagelanding_page

This distinction matters because HubSpot uses separate API endpoints for each type, and attempting to create a landing page through the site pages endpoint (or vice versa) will fail.

Pages built with HubSpot’s drag-and-drop editor have a layoutData structure that defines the visual layout. This structure is recursive and contains:

  • Layout sections — top-level horizontal sections of the page
  • Rows — horizontal arrangements within a section
  • Columns — vertical divisions within a row, with percentage-based widths
  • Widgets — the actual content modules placed in columns (forms, rich text, images, CTAs, custom modules, etc.)

JetStack AI walks the entire layout tree during deploy and remaps every internal reference found within widget parameters.

Pages can reference a wide range of other assets:

Dependency TypeWhere It Appears
TemplatesThe template the page is built on
BlogsBlog listing modules, recent posts widgets
FormsForm widgets (params.form_id), inline form embeds
HubDB tablesDynamic page data sources, HubDB table modules
Template modulesCustom modules used in DnD layouts and HubL includes
ImagesFeatured images, inline content images, background images

The page’s template path is remapped to the destination template’s path. If the template was not included in the import, the page cannot be deployed.

Pages are associated with a specific domain. JetStack AI supports domain mapping through the domains asset type configuration. Users specify which source domain maps to which destination domain. If no domain mapping is configured, JetStack AI uses the destination portal’s default domain.

The page’s featured image (used for social sharing previews and blog post thumbnails) is downloaded from the source portal and uploaded to the destination portal’s file manager. The page’s featuredImage URL is then updated to point to the new location.

Widget parameters are remapped recursively through the entire DnD layout tree. JetStack AI handles:

  • params.form_id — form widget form IDs are remapped to destination form IDs
  • params.hubdb_table_id — HubDB table references are remapped
  • Module paths — custom module references within widgets are remapped to destination module paths
  • Image URLs — images within widget parameters are uploaded and URLs rewritten
  • Link URLs — internal page links are remapped to destination page URLs where possible

Each layout section, row, column, and widget is traversed. JetStack AI preserves the structural layout (column widths, section styles, row configurations) while remapping all internal asset references within widget parameters.

The raw HTML/HubL content body is scanned for:

  • Image URLs (uploaded and rewritten)
  • HubL module tags with asset ID parameters
  • Internal link URLs pointing to other source portal pages
  • Form embed codes with source form IDs

JetStack AI uses a dual-endpoint strategy for page creation. It first attempts to create the page using the site pages API endpoint. If that fails (typically with a page type mismatch error), it falls back to the landing pages API endpoint. This approach handles cases where the page type detection is ambiguous.

Some pages have inconsistent pageType and subcategory values, especially pages created through the API or migrated between portals. JetStack AI uses both fields in combination to determine the correct endpoint. When they conflict, subcategory takes precedence.

Older HubSpot pages may contain protocol-relative image URLs (starting with // instead of https://). JetStack AI normalizes these to https:// before attempting to download and re-upload them.

Pages powered by HubDB tables use dynamic routing based on table row data. JetStack AI imports the page structure and HubDB reference, but the actual dynamic routes are determined by the destination HubDB table’s content. Ensure the HubDB table is deployed and populated before the page goes live.

Pages that use custom template modules in their DnD layouts depend on those modules being deployed first. If a module is missing, the widget will render as empty or display an error in the destination portal. Always include referenced template modules in the import.

If a page appears as a landing page when it should be a site page (or vice versa), check the source page’s pageType and subcategory values. Inconsistent values may cause misclassification. The deploy log will show which API endpoint was used.

If DnD widgets appear empty after deploy, the widget’s module reference likely could not be resolved. Check that:

  • The custom module was included in the import
  • The module deployed successfully
  • The widget’s params reference the correct module path

If the featured image is missing, check the deploy log for image upload failures. The source image URL may have expired, or the file may exceed the destination portal’s size limits.

If the page fails to deploy with a domain error, ensure that the domain mapping is configured correctly in the deploy settings. The destination domain must be connected and verified in the destination HubSpot portal.