Give Claude Code a Website's Page Layout

Contents

• [Map the page before describing the code](#map-the-page-before-describing-the-code)
• [Separate structure from styling](#separate-structure-from-styling)
• [Explain responsive behavior explicitly](#explain-responsive-behavior-explicitly)
• [Turn the observation into a build plan](#turn-the-observation-into-a-build-plan)
• [Use this in your AI agent](#use-this-in-your-ai-agent)

Give Claude Code a website's page layout by describing the page as a sequence of sections with clear hierarchy, widths, spacing, alignment, and responsive changes. Explain what each section is for, how it connects to the next one, and which decisions are structural rather than decorative.

Map the page before describing the code

Start with a section map from top to bottom. For every section, record:

• Its purpose and the visitor question it answers
• The content hierarchy, from heading to supporting copy to action
• The number of columns and the expected reading order
• The maximum content width and side padding
• The vertical spacing above and below it
• The background, border, card, or full-bleed treatment
• The transition into the next section

Use plain descriptions such as "centered headline followed by a two-column proof section" instead of vague labels such as "modern hero." A useful map lets Claude Code reconstruct the page logic even when exact assets or copy change.

The examples below include captures titled Notion Developer Platform, Claude Code, and Exa MCP Server. Compare them for section rhythm and long-page composition, but do not assume that a pattern in one capture is the correct structure for the site you are rebuilding.

Separate structure from styling

Your brief should have two layers. The first describes structure: section order, container widths, columns, stacking, alignment, and content relationships. The second describes visual treatment: colors, type scale, borders, shadows, radii, imagery, and motion.

This separation helps Claude Code create reusable sections instead of encoding every visual detail into one oversized component. It also makes review easier. You can decide that the page needs a feature grid even if the final card color, icon, or copy is still changing.

For each section, identify the primary alignment line. For example, the headline, body copy, and cards may share one left edge while a full-width image extends beyond that container. Call out intentional exceptions. Otherwise, a developer may normalize the page into a neat grid and remove the contrast that gives the composition its shape.

Explain responsive behavior explicitly

Do not ask for a layout that is merely "responsive." State what changes at smaller widths:

• Which columns stack first
• Whether the reading order changes
• Which decorative items disappear
• Whether padding tightens
• Whether cards become a horizontal scroll, a single column, or a smaller grid
• Whether a large heading wraps, scales, or uses a different line break
• Whether media crops, moves below text, or becomes a contained image

Also mark what must not change. A call to action may need to remain near the supporting copy. A diagram may need to keep its labels visible. A navigation action may need to stay reachable without requiring a wide viewport.

Turn the observation into a build plan

Ask Claude Code to return three outputs before implementation. First, a section tree with names and nesting. Second, a layout table with container, columns, gap, alignment, and breakpoint behavior. Third, a list of reusable patterns and one-off exceptions.

For typography, the Linear reference example identifies Inter at weight 400 for body copy, labels, navigation, and controls, and weight 500 for headings and emphasized interface text. Treat that as an observed example for comparison, not as a default for every project. If you use a reference, verify the actual family, weights, sizes, and line heights on the page you are reviewing.

Finish with a visual review checklist: section order, container edges, top-to-bottom rhythm, heading wraps, card heights, image crops, mobile stacking, and the position of the main action. A layout is ready for implementation when another person can follow the map without guessing what "clean" or "balanced" means.

Use this in your AI agent

> Review this website's page layout and return a build-ready brief for Claude Code. Map every section from top to bottom, explain its purpose and content hierarchy, record container width, columns, gaps, alignment, backgrounds, borders, and transitions, then describe the responsive changes at narrower widths. Separate structural observations from visual styling. Identify reusable patterns versus one-off exceptions, and include a checklist for section order, spacing rhythm, heading wraps, media crops, mobile stacking, and primary-action placement. Use the references below only to compare layout ideas, and clearly separate observed details from recommendations.

Install Fudge for your AI agent

Prioritize the details that change the page's structure or reading order. Give Claude Code the section sequence first, then the container width, column count, alignment, and major spacing for each section. Those decisions determine whether the implementation feels like the reference even when the exact images and copy differ.

Next, describe the responsive rules. Say which columns stack, which item comes first, what disappears, and how media changes shape. Include the position of the main action and any content that must stay together.

Typography and decoration come after that. Record heading scale, body size, weight, line height, borders, radii, shadows, and color roles, but tie each one to a component or section. A bare statement such as "use a clean sans-serif" is too open to interpretation.

Ask for a three-part plan. Part one is a section tree, such as navigation, hero, proof, feature grid, detail sections, and closing action. Part two is a layout table with one row per section and columns for width, columns, gap, alignment, background, and narrow-screen behavior. Part three is a component plan that marks repeated patterns and one-off sections.

Then request an assumptions list. It should call out missing copy, unclear breakpoints, uncertain asset behavior, and any place where the visual evidence is incomplete. Resolve those items before making them shared component defaults.

Before shipping, compare the implementation at the same viewport sizes as the reference. Check the left and right container edges, vertical rhythm, heading wraps, card heights, media crops, and action placement. If those match, small differences in icons or copy are easier to evaluate separately.

Related questions

• Give Claude Code a Website's Spacing Scale
• Give Claude Code a Website's Motion and Interactions
• Give Claude Code a Website's Typography Hierarchy
• Give Claude Code a Website's Image and Video Use