Fix your website's mobile layout

Kite decides which pages to fix first by looking at where phone visitors land and where they leave. A layout problem on a page nobody opens on a phone can wait. A cramped pricing page that half your mobile visitors reach can't.

On a site Kite hosts, its built-in analytics show which pages get the most visits, where visitors came from, and, on plans that include the detailed view, which device categories they used. Kite also runs Google's PageSpeed test, which scores how quickly your pages load on a phone and how accessible they are, so a page that's slow or hard to use on mobile stands out.

If you use Microsoft Clarity, connecting it gives Kite a sharper picture. Clarity counts rage clicks, which are bursts of fast taps on the same spot, along with dead clicks on things that look tappable but aren't. Kite can split those counts by device. If phone visitors rage-tap your signup button far more often than laptop visitors do, that points to the mobile layout rather than the offer.

Related How-to pages

• How to find where website visitors get stuck with Microsoft Clarity: Read Clarity's rage clicks, dead clicks, and scroll depth by page and device to find where phone visitors struggle, then fix the worst problem first.

Kite looks at your pages at phone width to find what's wrong, because many mobile problems never show up on a laptop. It opens each page in a browser, renders it the way a visitor would see it, and captures screenshots of the problem areas.

It looks for the specific failures that make a page feel broken. It checks whether anything runs wider than the screen, whether headlines wrap cleanly or get cut off, and whether an image or a decorative shape covers text. It also checks whether the main call to action is visible without much scrolling and whether buttons are large enough to tap.

When you sign up for Kite with the goal of converting more of your website visitors, this check starts right away. Kite reviews the first screen of your homepage on a phone and tells you whether it fits the screen and whether visitors can see a call to action before they scroll.

Kite fixes each problem at its source, which is usually one shared piece of the site rather than each page separately. If the headline style clips text on twelve pages, Kite changes the headline style once. If the footer pushes the page wider than the screen, it fixes the footer, and every page that uses it is fixed with it.

The changes themselves are specific. Kite might:

• stop an oversized image or table from pushing the page past the edge of the screen
• let a large headline wrap onto two lines instead of being cut off
• remove an overlap that works on desktop but hides the headline on a phone
• stack a three-column section into one column on small screens
• turn a row of cards into a row visitors can swipe through
• move the main call to action higher on the phone version of the page

Kite changes only what's broken. When it resizes text, it keeps the phone size and the desktop size in proportion, so a headline that gets bigger on desktop never shrinks on a phone. It also leaves the sections that already work exactly as they were, so a mobile fix doesn't quietly change the design of your desktop site.

You fix a mobile menu by checking the four things that usually break: whether the button opens it, whether it's readable once open, whether its links work from every page, and whether it's easy to use with a thumb. Kite checks and fixes each one.

A menu that opens with a see-through background on top of a busy page is hard to read, so Kite gives it a solid background unless your design calls for something else. A menu whose links point only to a section of the homepage, such as a link to the features section, often does nothing when a visitor taps it from another page. Kite writes those links so they lead back to the right section of the homepage from anywhere on the site. Kite also makes the menu slide in smoothly, sizes its links for tapping, and keeps the same menu on every page so visitors don't find a different one on your blog.

If the menu button does nothing at all, the cause is often an error in the code behind it. On a site Kite hosts, its error reports show the errors visitors run into and the pages where they happen, which helps Kite find and repair the broken code.

You see every mobile fix before your visitors do. On a site Kite hosts, the finished changes wait as unpublished changes, and you can switch the preview between desktop and mobile.

When you're happy, approve the work with the Publish button or a reply in the conversation, in the Kite web app or in Slack. Kite publishes the changes together and checks that the site displays correctly. You can then scan a QR code to open the live site on your own phone, which is the most reliable way to judge whether a menu feels right under your thumb. If something looks wrong later, you can undo that one change and keep everything published after it.

If your site's code lives in your own GitHub repository, Kite merges the fix into your default branch and your own deployment ships it. If that branch is protected, Kite opens a pull request for your team to review instead.

Kite measures each fix by how phone visitors behave afterward. Shortly after each publish, Kite runs Google's mobile PageSpeed test on your homepage and emails the person who published if the site has become slow on phones or the homepage has grown too heavy.

Over the following days, Kite compares the changed pages with their numbers from before the fix. On a site it hosts, it reads visits, bounce rate, and conversions from its built-in analytics. With Clarity connected, it checks whether rage clicks and dead clicks on phones have dropped. If a problem persists, Kite looks for the next cause. You can also ask Kite to check your site's mobile experience on a schedule, so a new problem gets caught when it appears rather than weeks later.