Inspect a Website's Page Layout from Its URL
Learn how to map a website's page layout, sections, spacing, and components from a captured URL without copying its design blindly.
inspect a website's page layout from its url
You can inspect a website's page layout from its URL by capturing the page, mapping its sections, and recording the rules that repeat from top to bottom. The useful result is a layout map you can compare with your own page before rebuilding it.
Start with a layout map
Capture the page at the target URL, then write down the visible structure from top to bottom:
- Header and navigation
- Announcement or secondary navigation, if present
- Hero content, including heading, supporting copy, buttons, and media
- Main feature or proof sections
- Repeated cards, tables, testimonials, or product views
- Calls to action
- Footer navigation and legal content
For each section, record whether it is full-width or contained inside a centered wrapper. Note the approximate content width, left and right gutters, column count, and alignment of headings, text, media, and buttons. This gives you a practical wireframe rather than a screenshot to imitate.
Captured pages
Linear typography
- Inter
Weight 400
- Inter
Weight 500
Compare the captured examples
The captured Linear examples are useful for studying a consistent product-page treatment. Both use a near-black canvas, muted dividers, compact controls, and one cool accent. Compare the first visible screen, then check whether the same alignment and surface choices continue through later sections.
Look for repeated rules:
- Does the header share the same left edge as the hero text?
- Do feature sections alternate image and text positions, or keep one rhythm?
- Are cards equal in height, or do they follow their content?
- Do dividers span the viewport or stop at the content wrapper?
- Are buttons aligned to the text column or centered within a larger panel?
- Does the footer reuse the same column grid as the body?
These checks help separate a page-wide layout rule from a one-off visual choice.
Inspect responsive behavior
A desktop capture is not enough. Check the page at a wide desktop width, a narrower laptop width, and a mobile width when those states are available. Record where the layout changes rather than simply shrinking:
- Navigation may collapse into a menu.
- Two columns may become one.
- Cards may become a horizontal scroll row or stack vertically.
- Decorative media may move below the text or disappear.
- Gutters may shrink while heading sizes change in steps.
- Buttons may stay inline, stack, or expand to the available width.
Mark each change as a breakpoint behavior. If you are recreating the page, implement those changes intentionally instead of relying on accidental wrapping. Keep observations separate from your own recommendations.
Turn observations into a build checklist
Before writing code, reduce your notes to a short checklist:
- Canvas color and section backgrounds
- Content wrapper width and page gutters
- Header height and navigation alignment
- Hero column proportions and media treatment
- Section spacing rhythm
- Grid or flex rules for repeated content
- Card borders, radii, and dividers
- Mobile stacking order
- Button placement and minimum touch size
- Footer column behavior
Inspect typography separately from layout. The supplied examples identify Inter in regular and medium weights, with contrast coming from size, weight, and muted color. That observation can explain why a page feels compact without confusing font choice with spacing choice.
A good inspection describes what the captured page visibly does. It does not prove that you own the original site's internal design system, source files, or implementation. Treat the result as observed guidance, then make your own choices for content, accessibility, performance, and responsive behavior.
Use this in your AI agent
> Inspect the captured website at this URL: [paste URL]. Return a top-to-bottom section map, container widths, column and alignment rules, repeated components, responsive changes at desktop and mobile widths, and a concise implementation checklist. Separate observed details from recommendations, and do not assume access to the site's internal design system.
Install Fudge for your AI agent to inspect captured references while you work.
How do I turn the layout inspection into a wireframe?
Turn the inspection into a wireframe by giving every section a name, a rough height, a content width, and a layout rule. Start with boxes, not colors or final copy.
For example, describe a hero as: centered wrapper, two columns, text on the left, product image on the right, one primary button, and a stacked layout below the mobile breakpoint. Describe a feature section as: contained wrapper, text column, media column, 64px section gap, and alternating order on every second section. Exact pixel values can wait until the structure feels right.
Use one line per section and include the mobile order beside the desktop rule. Mark shared patterns such as the header, buttons, card shell, divider, and footer grid as reusable components. Compare the wireframe with the captured examples to see which rules repeat across the page. This prevents you from copying a screenshot while preserving the rhythm that makes the reference coherent.
What should I check before rebuilding a reference layout?
Check five things before rebuilding it. First, confirm the content hierarchy: the main heading, supporting explanation, primary action, and proof should be easy to identify without relying on styling. Second, check whether the layout still works when headings wrap to two or three lines. Third, test the narrowest mobile state, including navigation, cards, buttons, and media cropping.
Fourth, check repeated spacing rather than measuring every gap independently. A page usually feels consistent because related elements share a small set of distances. Fifth, decide which parts are inspiration and which parts need a different treatment for your content, audience, accessibility needs, or brand.
Keep a short record of observed facts and a separate list of your decisions. That separation makes later revisions easier and avoids treating an inspection as proof of the original implementation.