Make an AI-Generated Website Mobile Ready

A mobile-ready page reflows its content; it does not shrink the desktop page until it fits. Start with a real rendered page, record failures at fixed widths, repair the element that causes each failure, and rerun the same checks. This guide is for an AI-generated page that already exists. If you are still designing frames in Figma, use the responsive Figma design guide.

The deliverable is a failure log with before and after results. A generic prompt such as "make it responsive" cannot show whether the navigation, forms, or long headings still fail on a narrow screen.

Which widths should you check first?

Open a local preview and record the URL and commit. Check 360 px and 390 px for phones, 768 px for the middle, and 1440 px for desktop. These are test widths, not all device sizes. Drag between them too; a defect may hide at the named widths.

Check the viewport tag. A missing <meta name="viewport" content="width=device-width, initial-scale=1"> can make a phone browser present a desktop-sized layout scaled down to unreadable text. MDN explains this behavior in its responsive design guide (accessed 2026-09-23). Adding the tag is necessary when it is absent, but it does not repair a fixed-width grid.

Set exact widths in browser developer tools. If the project already has Playwright, page.setViewportSize() makes checks repeatable; see its emulation guide (accessed 2026-09-23). Manual checks also work.

What belongs in the failure log?

For each failure, record width, element, visible symptom, cause, change, and retest result. A screenshot link helps, but a sentence must still describe the defect. Here is a hypothetical record, not a measured customer result:

Prioritize blocked tasks over cosmetic differences. If a visitor cannot read the headline, open the menu, or submit the contact form, fix that before polishing a margin. A browser console error, a missing image, and a horizontal scrollbar are separate failures. Do not group them under "mobile styling."

How do you find the element causing horizontal scroll?

First confirm that the page itself scrolls sideways, rather than an intentional carousel. In the browser console, compare document.documentElement.scrollWidth with window.innerWidth. If the first value is larger, inspect wide elements in developer tools and their computed widths. A fixed width: 900px, a long unbroken URL, a grid child that refuses to shrink, or an absolutely positioned image may be responsible.

Do not hide the evidence with overflow-x: hidden on the whole page. That can make the scrollbar disappear while content stays unreachable. Fix the responsible element. For a responsive image, max-width: 100%; height: auto; is a common baseline. For a grid item containing long text, min-width: 0 may let it shrink. For a text URL, allow wrapping where the content requires it. MDN describes fluid images, flexible layout, and media-query breakpoints in its responsive guide (accessed 2026-09-23).

What should change in the layout?

Start from the narrow layout's reading order. Decide whether the page should stack image, headline, proof, and action in that order. Preserve the meaning of the desktop page; do not remove essential terms or hide the only contact route just to make a screenshot fit. Use a single column where the available width cannot support two. Let cards wrap or stack. Set a sensible maximum content width for desktop so lines do not become too long.

For example, if an AI agent generated a three-column card row with fixed columns, ask it to replace that rule with a layout that becomes one column when cards cannot fit. Name the failing width and keep the content and links unchanged. Give the agent the failure log and require it to explain the CSS rule it changed. Review the actual diff. A media query at one width is not proof of success; test the intermediate widths too.

Navigation needs a real narrow-screen state. If links no longer fit, use a menu button that opens and closes a visible list, has a useful accessible name, and can be operated with the keyboard. Do not substitute a decorative menu icon that does nothing. If the site has a form, check labels, field widths, error text, and the submit action. A compact visual layout does not prove that the form delivers anything; the contact-form guide covers that separate test.

How do you know the repair is complete?

Reopen the page at every recorded width. Mark each log row as passed only after the original symptom is gone. Check portrait and landscape on at least one real phone when available, because emulation cannot cover every keyboard, browser chrome, or touch behavior. Use the keyboard on desktop to check menu and control focus. Zoom text and check that headings, labels, and buttons still fit. A layout that looks good only at its screenshot width remains fragile.

• The viewport tag is present and the page has no unintended horizontal scroll.
• Text stays readable and no content or control is clipped at each test width.
• Navigation and primary action remain usable without hover.
• Images keep the intended subject in view.
• The same page still works at desktop width.
• Each failure-log row includes its retest result and screenshot or observation.

For an existing site, AI with your website can help you write a narrow repair prompt from your observations. It does not run the viewport tests or edit your host. The Figment AI editor remains an early-access request flow for a separate imported static copy. It is not a public mobile repair service or an arbitrary source-file importer. Keep the tested repair in the repository that actually builds your site.

Sources and access date

• MDN responsive design, accessed 2026-09-23. Supports viewport, fluid image, and breakpoint guidance.
• Playwright emulation, accessed 2026-09-23. Supports optional repeatable viewport checks.