Preview your site on mobile

| Field | Value ||---|---|| Audience | SGEN site owners, content editors, marketing managers || Page type | guide || Area | Get Started || Updated | 2026-05-25 |

How to preview your site on mobile and confirm it looks right before you publish

Your site is not done when it looks right on your desktop monitor. More than half of web traffic arrives on a phone. On a typical SGEN site, 60 percent or more of visitors land on mobile. If a page layout breaks at that screen width, that is not a cosmetic issue. It is a broken experience for the majority of the audience.

SGEN includes a built-in mobile preview directly inside the page editor and the blog editor. The breakpoint switcher lets you step through six standard screen widths — 1920, 1199, 991, 767, 575, and 480 pixels — without leaving the admin dashboard, without opening a separate tool, and without deploying to a staging URL. You see the layout adjust in real time as you switch widths.

This guide covers the complete mobile preview workflow: opening the preview, stepping through breakpoints, identifying layout issues, applying per-device style fixes in SG-Builder, and confirming the page is clean before publishing. Building this workflow into your routine adds about five minutes to each publish. It catches broken hero sections, overflow images, and navigation elements that disappear at 480 pixels — all before any visitor sees them.

The preview is a browser-based approximation of mobile widths. It is not a real-device test. What it is: fast, accurate enough to catch layout problems, and built into the same interface where you make the fixes. For a brand-new page, this check is non-negotiable. For a small copy edit on an existing page, you can make a judgment call.

What is this for?

Mobile preview in SGEN is for confirming that a page or post renders correctly across the range of screen widths your visitors use — before the content is published and before a real visitor encounters a broken layout.

The breakpoint switcher is available in three places: inside the SG-Builder visual editor (the primary build surface), on the standard page edit screen via the Preview button, and on the blog post edit screen via the Post Preview link.

The breakpoint switcher is the core of mobile preview. It sits in the editor toolbar as a row of width buttons. Clicking a width immediately resizes the editor canvas to that viewport, letting you see how your content reflows. The six widths are:

Width	Label	What it represents
1920px	Desktop XL	Large monitor / widescreen
1199px	Desktop	Standard laptop / desktop monitor
991px	Tablet landscape	iPad landscape, large Android tablet
767px	Tablet portrait	iPad portrait, medium tablet
575px	Mobile large	Large-screen phones (iPhone Pro Max)
480px	Mobile small	Standard phones, narrow screens

For most sites, the widths that matter most for catching problems are 767px (tablet portrait), 575px (large phone), and 480px (small phone). Desktop layout is what most people edit in. Mobile is where most visitors arrive.

Good use cases

Mobile preview is the right check in each of these situations.

• Pre-publish check on any new page. Run a full breakpoint

sweep before every page publish. The rule is simple: if you built it, you check it at mobile. The breakpoint switcher is three clicks away from the Save button. There is no excuse for skipping it.

• Campaign landing page QA. Campaign landing pages —

holiday gift guides, limited-release launches — are dense with images, offer blocks, and countdown timers. Every one of those elements can break at 480px. Before any campaign goes live, run a full six-breakpoint sweep and compare against the design mockup.

• Post-edit verification after a content change. A hero

image changed on an About page. The new image had different dimensions. The desktop layout looked fine. The 575px preview showed the image overflowing the container by about 40 pixels. Five minutes of SG-Builder style adjustment fixed it before anyone published.

• Blog post preview before publishing. Long-form posts

with pull quotes, embedded images, and data tables all behave differently on mobile. The blog post editor's preview link opens a full rendered preview where you can use browser DevTools to check mobile widths, or you can use the editor's built-in preview at 575px.

• Template review after a global template change. If your

team updates a shared template — a header, a footer, a sidebar widget — the change propagates to every page that uses it. Before saving a template update, check it at all six breakpoints. One bad padding rule in a header template can break the mobile layout of a hundred pages at once.

• Mobile-only campaign QA. Some campaigns are designed

to reach an exclusively mobile audience — SMS links, mobile-app referral pages, Instagram bio links. These pages are viewed entirely on phones. For these, the 1920px and 1199px breakpoints are irrelevant. The 575px and 480px previews are the only ones that matter, and they need to be perfect.

• Accessibility spot-check. Tap targets on mobile —

buttons, links, form fields — should be at least 44px in height and width. The breakpoint preview lets you visually estimate whether buttons are large enough to tap reliably. It is not a full accessibility audit, but it catches the most obvious tap-target problems before they reach real users.

What NOT to use this for

• **Real-device testing is not replaced by the breakpoint

switcher.** The SGEN preview simulates viewport widths in a desktop browser. It does not replicate touch behavior, device-specific font rendering, OS-level zoom, or browser chrome (the address bar, bottom navigation bar) that shrinks the visible area on real phones. For high-stakes pages — homepage, checkout, campaign landing pages — supplement the SGEN preview with a real device test. Open the published page on an actual phone before the campaign goes live.

• Accessibility auditing is not what this is for. The

breakpoint switcher helps you spot visual layout problems. It does not evaluate contrast ratios, screen-reader compatibility, keyboard navigation, or ARIA attributes. For a genuine accessibility audit, use a dedicated tool — Lighthouse, axe DevTools, or a manual screen-reader test. The SGEN preview catches broken layouts; it does not certify accessible ones.

• Performance testing is a separate task. A page can

look correct at 480px and still load in eight seconds on a mobile network. The preview does not measure load time, image sizes, or render-blocking resources. Use Google PageSpeed Insights or a comparable tool for performance validation. The SGEN preview answers "does it look right" — not "does it load fast."

• **Do not use the preview as a substitute for saving

your work.** The breakpoint switcher shows you the current saved state of the page. If you have unsaved edits in the SG-Builder editor, the preview reflects whatever was last saved — not your in-progress changes. Save before you preview.

• This is not a cross-browser compatibility check.

The preview renders in your desktop browser. Layout differences between Chrome, Safari, and Firefox on mobile can vary, particularly for CSS grid, flexbox edge cases, and font rendering. If your site has a large Safari audience (common on iOS), verify on a real iOS device in addition to the SGEN preview.

How this connects to other features

Mobile preview sits at the intersection of several SGEN features. Understanding those connections helps you move efficiently from preview to fix.

• SG-Builder (per-device styles) — This is where you

fix what the preview reveals. SG-Builder's breakpoint switcher and per-device style tools let you set different padding, font sizes, image dimensions, and layout behavior for each screen width. A layout fix in SG-Builder is applied only to that component and that breakpoint — it does not affect other components or other widths unless you explicitly extend it.

• Pages — Every page in SGEN that was built with

SG-Builder has full breakpoint switcher access inside the editor. Pages built with the standard rich text editor have a preview link that opens a responsive browser preview. Both paths are covered in this guide.

• Blog — Blog posts have a Post Preview link on the

edit screen. The preview opens the rendered post in a new tab in your browser's default width. To check mobile, use your browser's responsive design mode (F12 → toggle device toolbar in Chrome) on that preview tab, or use the 575px and 480px estimates from SGEN's built-in breakpoint reference table above.

• Templates — Site-wide templates (header, footer,

shared sections) are built and edited in the template editor, which also has the breakpoint switcher. Changes to a template propagate to every page that uses it. Always preview a template change at all six breakpoints before saving.

• Custom CSS — Mobile-specific style overrides can be

added in Custom CSS at the site level. Custom CSS is appropriate for small, targeted fixes — hiding a decorative element on mobile, adjusting a font size for a specific element class — but it is not a substitute for per-device styles in SG-Builder. If you find yourself writing more than five lines of mobile-specific Custom CSS for a single layout problem, the root cause is probably the SG-Builder component configuration, not a CSS patch opportunity.

• Publishing workflow — Mobile preview is the last

gate before publishing. The sequence is: edit content → save → preview at each breakpoint → fix any issues → save again → preview again → publish when clean. Do not publish a page you have not previewed at 575px and 480px.

Before you start

Confirm the following before you open the preview.

The page or post is saved. The breakpoint preview reflects the last saved state. Any unsaved edits in the editor will not appear in the preview. Hit Save or Update before opening the breakpoint switcher.

You know your top traffic screen widths. Check your analytics (Google Analytics, Plausible, or whichever tool your site uses) to see the screen widths and devices your visitors use. Many sites see 60 percent mobile, with the majority on phones between 375px and 430px — putting the 480px breakpoint at the center of the real-world audience. If your site is used primarily on desktop (common for B2B tools or admin-facing tools), the weight you assign to each breakpoint shifts accordingly.

You know what "correct" looks like for this page. Before you start previewing, have a reference: the design mockup, a screenshot of a working version, or a clear mental model of the intended layout. You cannot spot a broken layout if you do not know what the correct one looks like. Keep a design mockup or screenshot for every campaign page and pull it up alongside the SGEN preview before starting the breakpoint sweep.

You have access to SG-Builder if the page was built there. If the page uses SG-Builder components, you will need the SG-Builder editor open to apply any fixes you find. Confirm you have edit access to the page before you start the preview sweep.

Where to go

For pages built with SG-Builder: Navigate to the page in your Pages list, click Edit, then click SG-Builder to open the visual editor. The breakpoint switcher appears in the top toolbar of the SG-Builder editor as a row of width icons or dimension labels (1920 / 1199 / 991 / 767 / 575 / 480).

The SG-Builder editor loads with the page at desktop width by default.

For standard pages (not using SG-Builder): Navigate to the page in your Pages list, click Edit. On the edit screen, click the Preview button (top right or below the page title, depending on your SGEN version). The preview opens in a new browser tab. Use your browser's developer tools (F12 → device toolbar) to simulate mobile widths on that preview tab.

For blog posts: Navigate to the post in your Blog list, click Edit. Click the Preview link (typically labeled "Preview Changes" or "View Post Preview"). The preview opens in a new browser tab. Use browser DevTools to check mobile widths, or reference the breakpoint width table earlier in this guide.

Steps — Preview your site on mobile and fix what you find

These steps take you from a saved page to a confirmed, mobile-ready layout across all six breakpoints. Follow them in order. Do not skip the 480px step — it is the smallest width and the most likely to reveal overflow and wrapping problems that do not appear at larger widths.

1. Open the page in the SG-Builder editor

Navigate to Pages in your SGEN dashboard left sidebar. Find the page you want to check. Click Edit.

On the page edit screen, click SG-Builder to enter the visual editor. If the page was built with SG-Builder, this button is visible. If it was built with the standard rich text editor, use the standard Preview button instead and follow the browser DevTools path described in the Where to go section above.

The SG-Builder editor loads at the desktop breakpoint (1920px or 1199px) by default. The canvas shows your page at full desktop width.

2. Open the breakpoint switcher and select the first mobile width

With the SG-Builder editor open, locate the breakpoint switcher in the top toolbar. It displays as a row of width options: 1920, 1199, 991, 767, 575, 480. You may also see device icons (monitor, tablet, phone) that correspond to the same widths.

Click 767 to switch the canvas to tablet portrait width. The layout adjusts immediately. Watch for:

• Text that was in two columns shifting to a single column
• Images that reflow or resize
• Navigation menus that collapse into a hamburger menu icon
• Spacing that tightens or expands
• Any element that disappears entirely

Take a mental note or a quick screenshot of anything that looks unexpected. Do not make fixes yet — complete the full sweep first so you have a complete list of issues before you start editing.

3. Step through each breakpoint and log issues

Work through the breakpoints in descending order: 767 → 575 → 480. These three widths cover the mobile range your visitors use. The 991px, 1199px, and 1920px widths are worth a quick scan but are less likely to reveal phone- specific problems.

For each breakpoint, check the following:

Horizontal scrollbars. If the preview shows a horizontal scrollbar at the bottom of the canvas, something is overflowing. An element — most commonly an image, a fixed-width container, or a wide table — is wider than the viewport. Note which section it is in.

Text overflow. Long words, unbroken URLs, or text inside fixed-width containers can overflow their parent element on narrow screens. Look for text that is clipped, runs off the visible area, or overlaps another element.

Images that are too wide. Images without max-width constraints expand to their natural pixel width on narrow viewports. A 1200px image on a 480px canvas causes a horizontal scroll and pushes other content off-screen.

Tap targets. Buttons and links should be large enough to tap reliably — aim for at least 44px in height and width. If a button looks visually small at 480px, it is probably too small to tap accurately. Note it.

Font size. Body text below 14px is difficult to read on mobile without zooming. Headlines below 20px lose visual hierarchy. Note any text that looks too small.

Navigation. If your site uses a navigation menu, confirm it collapses correctly into a mobile menu at 767px and remains usable at 480px.

Hero sections. Full-width hero images and hero text blocks are common problem areas. The image may crop unexpectedly, the overlay text may overflow or disappear, or the call-to-action button may not render correctly.

Log your issues. A simple list in a notepad or a shared doc is enough. A simple table with three columns works well: breakpoint, element, problem description. Fill it in during the sweep and work through it top-to-bottom when you get to the fix step.

4. Fix per-device styles in SG-Builder

With your issue list in hand, stay in the SG-Builder editor and click the breakpoint where the first problem occurs. Select the component that needs fixing.

SG-Builder applies styles per device. When you are at the 480px breakpoint in the editor, any style changes you make to a component apply only to that breakpoint — they do not affect the desktop layout. This is the correct behavior: fix mobile without breaking desktop.

Common fixes and how to apply them:

Image too wide. Select the image component. In the style panel, set Max width to 100% at the mobile breakpoint. This constrains the image to the container width without affecting its desktop size.

Text overflowing its container. Select the text component. Check if a fixed pixel width is set on the component or its parent. Change fixed pixel widths to percentage values at the mobile breakpoint. 100% for full-width text blocks is the most common correction.

Button too small to tap. Select the button component. At the mobile breakpoint, increase the padding top and bottom (aim for at least 12px top/bottom so the total button height clears 44px when text is included). Increase font size if it is below 14px.

Column layout not stacking. If a two-column or three-column layout is not collapsing to a single column at 767px or below, check the component's layout settings at that breakpoint. Set the flex direction to column or set the grid columns to 1 at the mobile breakpoint.

Font too small. Select the text component. At the mobile breakpoint, increase the font size. Body text at 15px-16px is a reliable starting point. Headline size should be reduced from desktop to avoid overflow but maintained above 22px for visual hierarchy.

After each fix, do not immediately move to the next issue. Save first. Then check the fix at the breakpoint where the problem was, and also quickly check the breakpoints above it to confirm the desktop layout was not affected.

5. Save and re-preview after fixes

After applying fixes, save the page. Click Save or Update in the SG-Builder toolbar. Wait for the save confirmation before switching breakpoints.

Return to the breakpoint where the problem was and confirm the fix worked. Then step through all six breakpoints again — a full sweep, not the ones you edited. Style changes in SG-Builder can have cascading effects. A fix at 480px can occasionally affect 575px if the style is inherited rather than explicitly set per breakpoint.

If the fix did not work as expected:

• Confirm you were at the correct breakpoint when you applied

the style change. Styles set at one breakpoint do not automatically apply to narrower ones unless the cascade flows that direction.

• Check whether the component has a fixed width set at the

site-wide CSS level (Custom CSS). A Custom CSS rule with !important will override SG-Builder per-device styles.

• Check whether the parent container has a fixed width that

is constraining the child component.

Repeat the fix → save → re-preview cycle until all six breakpoints show a clean layout.

6. Run a final six-breakpoint sweep and confirm clean

Before publishing, do one last complete sweep: 1920 → 1199 → 991 → 767 → 575 → 480. This is the confirmation pass — slower and more deliberate than the issue-finding pass in Step 3.

On this pass, check the four mobile success criteria:

No horizontal scrollbars. Scroll slowly down the page at each mobile breakpoint. If a horizontal scrollbar appears at any point, there is still an overflow issue somewhere on the page. Find the offending element and fix it before continuing.

All text is readable without zooming. At 480px, the smallest text on the page should be comfortably readable on a phone held at normal reading distance. If you have to mentally squint to read it in the preview, a real visitor will pinch-zoom — and that is a broken experience.

All tap targets are large enough. Buttons, links, navigation items, and form fields should all visually occupy at least 44px of height. If a button looks like a thin sliver at 480px, note it and fix it.

No content disappears unintentionally. Some elements are legitimately hidden at mobile (decorative backgrounds, wide data tables replaced by a summary view). But if a call-to-action button, a key headline, or a form has disappeared at a mobile breakpoint, that is a bug.

When the six-breakpoint sweep is clean on all four criteria, the page is ready to publish.

7. Publish when the layout is clean

With the final sweep complete and all four criteria passing at all mobile breakpoints, publish the page.

In SG-Builder, click Publish in the top toolbar. The page status changes from Draft to Published. After publishing, open the live URL on your phone (not the preview — the actual published page) and scroll top to bottom. It takes thirty seconds and catches any discrepancy between the preview and the live render.

If you are publishing for the first time and the page is high-stakes (a homepage, a campaign page, a product launch page), do the same. Open the live URL on a real phone after publishing. The SGEN preview caught the layout problems. A thirty-second real-device scroll confirms the fix held on the actual device.

What success looks like

When mobile preview is complete and the page is ready to publish, these things are true.

• The page has been previewed at all six breakpoints:

1920, 1199, 991, 767, 575, and 480.

• No horizontal scrollbar appears at any breakpoint when

you scroll down the full page.

• All text on the page is readable at 480px without the

visitor needing to pinch-zoom.

• All buttons, links, and form fields are visually large

enough to tap — at least 44px in height.

• Images are constrained to their containers and do not

overflow the viewport at any mobile breakpoint.

• Navigation collapses correctly at 767px and remains

usable at 480px.

• No content that should be visible at mobile has

disappeared unintentionally at 575px or 480px.

• Per-device style fixes have been applied at the correct

breakpoint in SG-Builder and the desktop layout is unaffected by those changes.

• The final six-breakpoint sweep passes all four criteria:

no overflow, readable text, large tap targets, no missing content.

• The page has been published and optionally verified

on a real phone after publishing.

When this checklist is complete, the page has been through a proper mobile QA pass. The next step is the broader publishing workflow: SEO metadata check, Open Graph image, internal link review. Those are covered in the Pages publishing documentation.

What to do if it does not work

The preview still shows desktop layout even after clicking a mobile breakpoint. This happens when the breakpoint switcher click did not register, or when the page is using a fixed-width container that does not respond to the canvas width change. First: click the breakpoint button again and wait two to three seconds for the canvas to reflow. If the layout still does not respond, check whether the page's outermost container has a fixed pixel width set (for example width: 1200px with no max-width: 100% override). A fixed-width container ignores the viewport width and renders at its set pixel value regardless of breakpoint. Fix by adding max-width: 100% and width: 100% at the relevant mobile breakpoints in SG-Builder.

Text overflows its container at 480px but the SG-Builder style panel shows no fixed width on the text component. The fixed width is likely on the parent container, not the text component itself. Select the parent section or column in SG-Builder and check its width settings at the mobile breakpoint. A column set to width: 600px with no mobile override will overflow a 480px canvas regardless of what the text component inside it is set to.

An image is too wide at mobile and setting max-width 100% did not fix it. Check whether the image has a hardcoded width attribute in the HTML source (not in the SG-Builder style panel). Some images imported from legacy content have inline width attributes that override CSS. If the image is in an SG-Builder component, this should not be the case — but if the image was inserted via the rich text editor, it may have an inline attribute. Open the page source or use browser DevTools on the preview tab to check. Remove the inline width attribute.

A button looks large enough in the preview but still feels too small on a real phone. The SGEN breakpoint preview renders at a higher pixel density than your monitor. A button that appears to be 44px in the canvas may only be 30px at the actual device pixel ratio on a high-DPI phone. The rule of thumb: in the SG-Builder style panel, aim for at least 48px minimum touch target height (not 44px) to account for the pixel density discrepancy between the canvas and real devices.

A section disappears entirely at a mobile breakpoint. The component or section has a display hidden rule applied at that breakpoint. In SG-Builder, select the component and check the visibility settings at the mobile breakpoint. If you did not intentionally hide it at mobile, change the visibility setting from hidden to visible at that breakpoint. If the section was legitimately hidden (a desktop-only decorative section), confirm that equivalent content is visible at mobile — hiding a section should mean the mobile experience has a substitute, not less content.

Font appears small at 480px in the preview but looks normal on the desktop. The desktop breakpoint has a larger font size set than the mobile breakpoint. This is usually intentional — desktop headlines can be larger than mobile headlines. But if the mobile font size is below 14px for body text or below 20px for headlines, increase it. In SG-Builder, select the text component, switch to the 480px breakpoint, and increase the font size value. The change applies only to that breakpoint.

The navigation menu does not collapse at 767px. The mobile menu behavior is controlled by the site's header template and navigation settings. If the navigation is not collapsing at 767px, the issue is likely in the header template, not the page-level SG-Builder components. Open the template editor, select the header template, and check the breakpoint behavior of the navigation component. Alternatively, confirm that the mobile menu toggle (the hamburger icon) is configured in the navigation widget settings.

The preview and the live published page look different. The SGEN breakpoint preview reflects the saved state at the time of preview. If you published after making changes, check whether those changes were fully saved before publishing. Clear your browser cache and hard-refresh the published page (Ctrl+Shift+R on Windows, Command+Shift+R on Mac). If the discrepancy persists after a hard refresh, contact your SGEN support team with a screenshot of the preview and a screenshot of the live page at the same breakpoint.

A few habits that make mobile preview stick

These are the decisions that separate teams whose pages break on mobile (and stay broken until a visitor reports it) from teams where broken mobile layouts get caught at the source.

Build the mobile check into your page publishing checklist. A simple four-item checklist works: title and meta saved, preview at 480px, preview at 575px, publish. The checklist takes ninety seconds and catches every mobile layout problem before any visitor sees it. Make the breakpoint sweep a non-optional step in your team's publishing process, not an afterthought when someone complains.

Fix the cause, not the symptom. A text overflow at 480px is rarely a text problem. It is almost always a container width problem — a parent element with a fixed pixel width that does not have a mobile override. A button that is too small is almost always a padding problem, not a font-size problem. Take thirty seconds to understand what is causing the visual issue before reaching for a fix. A correctly diagnosed fix takes one edit. A symptom-level patch creates three new edge cases.

Check mobile after every significant content change, not initial page builds. A page that passed mobile review when it was built can break on mobile after a content edit. Adding a wide image, changing a headline length, inserting a data table — each of these can introduce a new mobile layout issue. The breakpoint switcher is a thirty-second check. Run it after significant edits, not only at initial publication.

Keep the breakpoint reference table handy. The six widths (1920 / 1199 / 991 / 767 / 575 / 480) are easy to memorize after a few sessions, but the labels — tablet landscape vs tablet portrait vs mobile large vs mobile small — matter when you are communicating a layout issue to a developer or a designer. Use the precise labels when you log an issue or file a support ticket. It eliminates ambiguity and speeds up diagnosis.

After any site-wide template change, preview every breakpoint before saving. This is the highest-stakes mobile preview scenario. A single bad padding rule in a shared header template can break the mobile layout of every page on the site simultaneously. The five minutes you spend previewing a template change at all six breakpoints before saving is worth more than the hour it takes to diagnose and fix a mobile regression that has already gone live on a hundred pages.

## Related reading

Topic
Publishing a page on SGEN
Per-device styles in SG-Builder
Previewing a blog post before publishing
Custom CSS — mobile-specific overrides
SGEN in 5 minutes