How PageHub Works

Know exactly where to make changes and where to verify results so you can publish with confidence.

Where you build vs what visitors see

This saves the most time when debugging.

  1. Build pages in the editor (Design on your site's dashboard).
  2. Check the draft on its preview link, then publish and review the live page.
  3. If it looks different, compare the same section on the preview and the live page first.
  • Editor controls only exist in the editor, and a site's own JavaScript does not run on the editor canvas.
  • Visitors see the published release, never your draft.

Where settings live

Change settings once in the right place instead of patching page by page.

  • A section's look is the Tailwind classes on its elements in the page's HTML.
  • The site-wide look (palette, fonts, spacing) lives in the theme; integrations, redirects, domain and timezone live under site settings.
  • If a setting is site-wide, change it once there instead of patching every section.
  • If a page behaves unexpectedly, check settings first before rebuilding blocks.

A simple debug flow

Run this sequence before you rebuild anything.

  1. Check the issue on the live page first (real output), then on the preview.
  2. Open the editor (Design on your site's dashboard) and check the same section and its settings.
  3. Verify integrations/redirects/site settings if the issue is behavior-based.
  4. Re-publish and test again in a fresh browser tab.

Common examples

Use this to go from symptom to first fix quickly.

  • Layout looks off after publish -> compare the same block in the editor, on the preview and on the live page.
  • Tracking not firing -> check integration IDs in site settings first.
  • Wrong URL behavior -> check redirect rules before touching page content.
  • Theme inconsistency -> verify the site's theme (palette and fonts) first.