Monitor your website for problems and errors

The checks that run after each publish answer one question: did this release break anything that affects how the site loads or how search engines read it? Kite looks only at what a visitor or a search engine would see from outside, and it checks these things:

• The homepage. Kite confirms it loads instead of returning an error.
• Pages that don't exist. Kite requests a made-up address and makes sure the site answers with a proper "not found" error. If it shows a normal page instead, search engines can index broken links as if they were real pages.
• The sitemap. Kite confirms there is a sitemap, that it is valid, that it lists pages, and that those pages are on your own domain. It also checks that the pages your homepage links to appear in the sitemap, so Google doesn't find them late or miss them.
• Structured data. Kite checks that the homepage carries structured data that search engines can read and that it says what kind of thing it describes.
• Speed and search basics. Kite runs Google's PageSpeed test on the homepage as a phone would load it. It flags a speed score under 50, a search basics score under 90, or a homepage that downloads more than 5 MB.

If any check fails, Kite emails the person who published with a plain description of each problem, such as "Your homepage downloads 7.2 MB when it loads." Large images and videos are the usual cause. Your site stays published either way, because the checks warn rather than block. Kite reports each problem to each person once. If a later check finds the problem fixed and it comes back afterward, Kite tells you again.

The site's Discoverability tab gives a fuller search and speed report with a list of issues, and you can hand any of them to Kite to fix.

Errors that only happen in a visitor's browser never show up when you load the page yourself, so the only reliable way to find them is to record them as they happen. Kite's built-in analytics records JavaScript errors on the sites it hosts, along with how often each one occurred, how many visitors it affected, and the page and line of code involved.

Kite uses that report to decide what to fix first. An error that fired twice for one visitor on an old blog post can wait. An error that fired 400 times this week on the pricing page, for nearly everyone who reached it, is probably costing you signups. Kite traces the most frequent errors back to the code that caused them and proposes a fix, starting with the ones on the pages that matter most to your business.

A page can load, pass every technical check, and still fail at the one job it has. Kite's website audit covers this by clicking your main call to action in a real browser and watching what actually happens, whether that's a form that opens, a checkout that loads, or a button that does nothing. Kite doesn't call a flow broken based on a link in the page code alone. It confirms the problem in the browser or labels the finding as unconfirmed.

The same audit looks for broken links and conversion paths that lead nowhere, checks that search and AI crawlers can reach the site, and grades the site's technical foundation alongside its messaging and conversion. It works on any public website, including one Kite didn't build, so it's also the way to check a site that runs on Webflow, WordPress, or your own code.

A sitemap problem rarely shows up as an error anyone sees. It shows up weeks later as pages that never get search traffic. For a site Kite hosts, Kite can submit the sitemap to Google Search Console after each publish and verify your domain for you, so new pages get crawled without anyone remembering to do it.

If you connect your own Search Console account, Kite can also read what Google sees. It checks whether a given page has been indexed and what issues Google reports against it, and it reads the health of your sitemaps, including how many of their pages Google has indexed and any errors or warnings. This works for a site Kite hosts and for one that runs anywhere else. It's how Kite confirms that a new page actually made it into Google instead of assuming it did.

Kite fixes problems wherever it has access to the site, and how it ships the fix depends on where the site runs:

• A site Kite hosts. Kite edits the code directly. Its finished changes wait as unpublished changes that you can preview, and when you publish, Kite ships them and checks that the site displays correctly. You can undo any single change without losing the ones after it.
• A site imported from GitHub. Kite makes the fix in your repository and merges it into your default branch, where your own deployment ships it. If that branch is protected, Kite opens a pull request instead.
• A site on Webflow or another connected CMS. Kite updates the pages, metadata, and structured data through your connected account and tells you whether each change is staged or live.

Kite also handles the errors that stop a site from working at all. When a site shows a blank page, returns a server error, or fails to build or deploy, Kite reads the logs to find the cause before it changes anything. For an imported site that won't build, it makes the smallest set of changes that produces a clean build while keeping your framework and code structure intact. If the fix needs something only you can provide, such as a missing secret or a decision about how the app should behave, Kite stops and tells you exactly what it needs.

Some problems appear without anyone changing the site. A third-party script breaks, a domain setting changes, or a page slowly gets heavier as images are added. To cover those, you can ask Kite to run a health check on a schedule, such as an audit of the homepage and pricing page every Monday morning, with the results sent to your Slack channel or by email.

Kite can also keep a standing watch on your site's traffic and tell you when it moves sharply. A sudden drop in visitors is often the first sign that a page broke or fell out of search.