Extract a Website's Page Layout

Learn how to map a website's sections, spacing, surfaces, controls, and responsive structure into a clear page layout reference.

extract a website's page layout

Contents

  • [Start with a section map](#start-with-a-section-map)
  • [Record the rules that repeat](#record-the-rules-that-repeat)
  • [Turn the map into a layout specification](#turn-the-map-into-a-layout-specification)
  • [Check the layout before rebuilding it](#check-the-layout-before-rebuilding-it)
  • [Use this in your AI agent](#use-this-in-your-ai-agent)

To extract a website's page layout, map the order, width, spacing, and relationship of its sections before copying visual details. Record what appears in each section, how the page moves the visitor forward, and which layout rules repeat across screens.

Start with a section map

Create a simple page outline from top to bottom:

  1. Header and navigation
  2. Hero message and primary action
  3. Product, service, or proof sections
  4. Supporting details, comparisons, or media
  5. Testimonials, trust content, or secondary actions
  6. Footer navigation and final action

For every section, note its purpose, content count, alignment, maximum width, background treatment, and spacing above and below. Mark whether the section is full width or sits inside a centered container. This gives you a layout model that can be rebuilt without relying on a screenshot alone.

The examples below are useful for comparing a consistent product layout. The captured Linear pages use a near-black canvas, muted dividers, compact controls, one cool accent, and Inter typography. The two examples show the same general treatment across different pages, so they are more useful for identifying repeatable rules than for copying one isolated section.

Captured pages

Linear typography

  • Inter

    Weight 400

  • Inter

    Weight 500

Record the rules that repeat

A good extraction separates content from structure. Write down rules such as:

  • page content sits inside a centered maximum width;
  • sections use a shared horizontal gutter;
  • headings align with body copy and controls;
  • dividers mark changes in content without adding heavy borders;
  • controls use a compact height and consistent radius;
  • one accent color identifies actions or selected states;
  • muted text creates hierarchy against the main canvas.

Then record exceptions. A hero may use a wider media area, a comparison section may use multiple columns, and a product screenshot may break the normal container width. Exceptions are easier to reuse when they are named instead of mistaken for the default.

Turn the map into a layout specification

Use a section table with these columns: section | purpose | width | columns | gap | surface | alignment | action | responsive change. Add a second table for shared components such as buttons, navigation items, cards, tabs, dividers, and form controls.

For responsive behavior, compare at least a wide and narrow view when both are available. Note what stacks, what disappears, what becomes scrollable, and which content keeps priority. Do not assume that a desktop grid simply becomes one column. A navigation bar may collapse, a sidebar may move below the main content, and a decorative panel may be removed entirely.

Typography belongs in the layout record because it changes the space a section needs. The Linear examples identify Inter at weight 400 for body copy, labels, navigation, and controls, with weight 500 for headings and emphasized interface text. Treat this as an observation from those captured examples, not as a universal rule for every page.

Check the layout before rebuilding it

Use this checklist before turning the reference into components:

  • Can each section be named by its visitor-facing purpose?
  • Is the main action clear without relying on color alone?
  • Do headings, copy, media, and controls share an alignment system?
  • Are container widths and gaps consistent where they should be?
  • Are dividers, surfaces, and accents doing distinct jobs?
  • Does the layout still work when text wraps or content grows?
  • What changes first at a narrow width?
  • Which observations need a second capture or direct verification?

A page review can include structure, components, viewport, page state, typography, colors, borders, radii, shadows, and gradients. For the complete workflow, see extract a design system from a website.

Use this in your AI agent

> Inspect the captured website and extract its page layout. Build a section-by-section map with purpose, order, container width, columns, spacing, alignment, surfaces, controls, and responsive changes. Identify repeated layout rules separately from one-off sections, include observed typography and color roles, and finish with a practical layout specification a designer or developer can rebuild.

Install Fudge for your AI agent.

How do I extract spacing and container rules without guessing?

Look for repetition before assigning a number. Compare the left edge of the header, hero copy, body sections, cards, and footer. If several sections share the same edge, treat it as a likely container gutter. Compare the gaps between headings, paragraphs, controls, cards, and section boundaries in the same way.

Record observations in relationships first: "the hero and feature grid share an alignment edge" or "card gaps are smaller than section gaps." Then assign values only after you have grouped similar gaps into a small scale. A practical draft might use small, medium, and large spacing tokens before choosing exact pixel values.

For containers, note whether content is centered, full bleed, or intentionally wider than the text column. Check whether media follows the text width or breaks beyond it. Repeat the review at another viewport if available, because a rule that looks fixed on desktop may become fluid on narrow screens. Mark uncertain values as estimates and verify them before turning them into shared components.

How can I turn a layout review into a rebuild plan?

Convert the review into three layers: page sections, shared components, and content data. First, list sections in order and define each section's purpose, width, columns, and action. Second, collect repeated elements such as navigation links, buttons, cards, tabs, dividers, and media frames. Third, describe each section's content as data so the structure does not depend on one screenshot.

Build the most repeated pieces first. Test the header, container, typography scale, button treatment, and card spacing before assembling the full page. Then implement one representative section from each layout pattern: a hero, a two-column feature, a grid, and a final action area.

Use the captured page as a comparison checklist, not as the only test. Check alignment, wrapping, hierarchy, surface contrast, and narrow-screen behavior. Keep a separate list of unknowns, such as missing interaction states or unobserved breakpoints. This prevents a clean-looking rebuild from quietly turning assumptions into permanent rules.