Site audit

A site audit crawls up to 50 pages of one website with JavaScript turned on, the way a browser sees them, and scores what it finds together with the site's latest AI readiness scan. Select Presence > Websites in the sidebar to find it. The site's page has four tabs: Overview, Issues, Backlinks, and Indexing. The audit fills the first two.

Run an audit

1. Select Presence > Websites. It opens your primary site. If you have more than one site, select the site's name at the top to switch.
2. Select Run audit at the top right. It's there on every tab, with "Up to 50 pages" next to it: one run covers up to 50 pages. After the first audit the button reads Run audit again.

While the audit runs, Overview shows Crawling with JavaScript, how many of the 50 pages are done, and a progress bar. Checked shows how long ago Mark last asked the crawler for progress. The page updates on its own every few seconds while it's open. You can't start a second audit on the same site while one is running.

Next to Run audit it says when the site was last checked, like "Last checked on 9/25". That's the date the last audit finished, or the last AI readiness scan if the site has never been audited. Home's Website readiness card shows the same date, behind its info icon, and the same Health score. View audit on that card opens this page at Issues by severity.

Run audits on a schedule

A site starts on Manual and audits only when you select Run audit. To audit it once a week instead:

1. Select Audit settings, the button next to Run audit. Under Schedule, choose one:
   • Manual: only when you click Run audit
   • Weekly: audits the site once a week
2. Select Save schedule.

With Weekly, Next audit shows the date and time of the next audit, one week after you save. With Manual, it says Manual. Saving a schedule doesn't start an audit, and selecting Run audit doesn't move the next scheduled one.

A scheduled audit shows up in the report the same way as one you started. If it fails, the next one runs a week later. It isn't retried sooner. Select Try again to rerun it yourself.

Read the health score

Overview starts with the health score, from 0 to 100, and the issue count for each severity. Next to them are seven category tiles, each with its own score and a count of issues per severity:

• Crawlability & indexing: broken pages, redirects, canonicals, and site structure.
• Rendering: whether pages show their content without JavaScript.
• On-page content: titles, descriptions, headings, and text.
• Structured data: errors in the page's schema markup.
• Performance & page weight: load time, page size, and compression.
• Security: HTTPS links.
• AI readiness: the score and issues from the site's AI readiness scan.

An eighth tile, Agentic readiness, shows how many of Google Lighthouse's experimental agentic browsing checks passed, such as "2 of 3", not a score. It never changes the health score. See Agentic readiness (experimental).

Each issue lowers the score by its weight: a Critical issue counts most, then Warning, then Notice. An issue on every page costs its full weight, and an issue on a few pages costs a share of it. The two Article and JavaScript structured data recommendations, the AI crawler access issue, and the main sections recommendation weigh nothing. A category with nothing checked shows n/a and doesn't count toward the health score.

The AI readiness tile shows the score from the scan's full report, which each of its issues links to. In the health score, each check the scan ran counts like a Notice.

The site's page shows the health score as a badge next to the site's name.

Select a tile to show only that category's issues. Select it again, or select Show all, to see every issue. On Overview the tiles filter Top issues; on Issues they filter the full list.

Read the action plan

Below the health score, Action plan says what to fix first. It's written by AI from this audit's findings, so check it before acting on it. It starts with a short summary, then sorts the fixes into three columns:

• This week: Critical issues, and anything that stops search engines from reading the site.
• Next: Warnings.
• Later: Notices and polish.

Each fix names the issues it solves, under Fixes, and how many pages they affect. Select an issue's name to open the Issues tab at its row in By issue. When the site shows a blank page without JavaScript, the first fix names a way to prerender pages for the tools the site is built with.

When the audit found a Critical issue, the plan's first fix goes to a Critical one, and the summary doesn't say none were found. Critical AI readiness issues count too, so the plan and Issues by severity agree.

When the plan doesn't cover every Critical issue on the report, its note says This plan does not cover every Critical finding. See Issues by severity. You'll see this on some older audits, whose plans were written before AI readiness issues counted as Critical. Work from Issues by severity instead, or select Run audit again for a new plan.

The plan only points at issues this audit found. It appears a minute or two after the crawl finishes, and until then says Writing the action plan…. If it can't be written, the report says so; every issue below is still complete, and the next audit tries again. An audit with no issues has nothing to plan. Audits that ran before the action plan existed don't show one.

AI judged issues

The same review adds up to four kinds of issue that need a reader rather than a rule. They carry an AI judged badge:

• H1 does not match the title's topic: the page's heading and its title name different things. The row shows both, and a suggested heading.
• Structured data lacks a type that fits the page: for example, a product page with no Product schema. The row lists the types to add.
• Organization structured data is incomplete: your Organization schema lists no social profiles in sameAs, or its logo isn't a logo. When you have saved identity links on Strategy > Brand and sameAs is empty, the row links to the ready-made Organization JSON-LD there, so you can copy its sameAs list into your existing schema.
• Page text does not cover what the page is for: a page whose main text doesn't back up its title and heading, for example a product page with one sentence about the product. The row says what to add and how many words the page's main text has, leaving out the header and footer. Mark reads the main text of every page that loaded. Pages with fewer than 400 words, in total or in the main text, are judged on their main text. Longer pages are judged on an outline of their sections (the first line of each), on up to 15 pages per audit. The review is told to leave contact, login, checkout, and legal pages alone, since their job needs little text.

They count toward the health score like any other issue. When the plan couldn't be written, these checks weren't run, so they don't raise the score either. The same goes for the page text check on audits reviewed before it existed.

Top issues

Under the action plan, Top issues lists the five worst issues, in the same order as By issue. Select View all issues to open the Issues tab.

Severity

Every issue carries one of three words:

• Critical: the page or site is broken, or search engines can't read it. For example, a page that returns an error, or a site that shows a blank page without JavaScript.
• Warning: hurts how search engines read or reach the page. For example, a missing meta description or a slow page.
• Notice: hygiene. For example, images without alt text.

AI readiness issues use the same words: essential is Critical, recommended is Warning, and bonus is Notice.

Work through the issues

The Issues tab lists every issue in two views.

By issue shows one row per check, Critical first. Within a severity, issues that affect the whole site come first, then the ones on the most pages. The Pages column says how many pages have the issue, for example "7 of 50", or Site-wide. Select a row to see:

• what the audit found, in plain words;
• one sentence on how to fix it, with a Learn how link to a public reference page;
• up to 10 of the affected pages, then how many more there are. Select a page to open its page view in Performance.

For an AI readiness row, the link opens the full AI readiness report instead.

By page lists the pages that have issues, worst first. Select a page to see its issues. See this page in Performance, above the issues, opens its page view. Site-wide issues aren't in this view.

The page view opens with its default dates, since the audit has none.

Both views show 10 rows at a time. Use Previous and Next below the list to see the rest.

Under both views, the report counts the pages with no issues, for example "12 pages had no issues".

See what changed since the last audit

When you rerun an audit, the report compares it with the finished audit just before it. Audits that are still running or that failed are skipped. On Overview, above the health score, one line gives the result, for example "Since the audit on Sep 17, 2026: 3 new issues · 4 fixed". If nothing changed, it reads "No new or fixed issues since the audit on Sep 17, 2026".

• In By page, a page with new issues shows how many next to its issue count, for example "2 new". Open the page and each new issue has a New badge.
• Fixed since lists each issue that went away, as the page address and the issue. Select it to open the list. It's hidden when nothing was fixed.

Only pages crawled by both audits are compared. The 50-page limit can reach different pages from one run to the next, so an issue on a page that only one audit crawled counts as neither new nor fixed. That includes a page you published since the last audit. Site-wide issues aren't compared either.

The first audit of a site has nothing to compare with. Neither does an audit run after the site's address changed, or one that shares no crawled page with the audit before it. Those show no comparison. While a new audit runs, Last finished audit keeps its own comparison.

The blank page alert

If search engines that don't run JavaScript see a blank page, a red alert sits at the top of Overview. It says how many sample pages were fetched without JavaScript and how to fix it: serve each page's own HTML through prerendering or server rendering. Select See the issue to open its row on the Issues tab.

This is the most damaging finding an audit can report. Until it's fixed, those search engines see the same empty page at every address on the site.

Article and JavaScript structured data

Two Notices about structured data are recommendations. They show on Issues like any other issue, but they don't change the health score or the Structured data tile's score.

Article structured data lacks recommended fields looks at each post or article the audit crawled. A page counts as one when its JSON-LD has an Article, BlogPosting, NewsArticle or TechArticle item, when its og:type is article, or when its address is under /blog/, /posts/, /articles/ or /news/ and the page has a publication date. The homepage, a /blog index, and its paging, tag and category pages are never checked.

The row lists what the page's Article JSON-LD is missing:

• no Article-family item at all (the row then lists every field below);
• headline;
• author, or an author that isn't a Person: plain text, or only an Organization;
• datePublished.

An author that points by @id to a Person elsewhere on the page, as Yoast writes it, counts as that Person.

Under Also recommended it lists dateModified, image, and a url or sameAs link for the author, when they're missing. These alone don't raise the row. Google lists these Article fields as recommended, not required. The fix is an author that is a Person with a name and a link to their profile.

Structured data appears only after JavaScript runs compares the JSON-LD the browser sees with the HTML your server sends, on the pages the audit fetches without JavaScript: the homepage, two more pages, and the first post when the site has one. This structured data appears only after JavaScript runs. Crawlers that do not run JavaScript will not see it. The row lists each page and the schema types missing from its HTML. Some crawlers run JavaScript and some don't, so this doesn't say a given one misses it. A page Mark couldn't fetch, or whose structured data is too large to read in full, is skipped, not reported.

Audits that ran before these checks existed don't show them.

Redirect and trailing-slash checks

Three site-wide checks look at how the site's addresses redirect. Each row lists up to five example addresses with the status code they answered and where they point, then how many there are in total.

• Internal URLs use temporary redirects (302, 303 or 307), a Warning: a page on the site redirects to another page on the site with a temporary status. Search engines can keep the old address as the one they show. Change it to a 301 or 308, which moves the address for good.
• Pages load both with and without a trailing slash, a Warning: for example, /pricing and /pricing/ both show the page instead of one redirecting to the other. Search engines see two copies. Pick one form, 301 redirect the other to it, and link to that form everywhere.
• Canonical points to a URL that redirects temporarily, a Notice: a page's canonical tag names an address that answers 302, 303 or 307. Point the canonical at the address the redirect ends at.

To find these, the audit reads the crawl's internal links and requests up to 20 addresses that redirected in the crawl or its links or that canonical tags name, and the other slash form of up to 20 crawled pages. It only reads them; it never changes anything on your site. A path your links use in both forms is listed too, even when one form redirects.

Site structure checks

Three checks under Crawlability & indexing look at how the site links its main pages together. A footer that links every main section works as a map of the site for search engines and AI assistants.

• Header and footer do not link to every main section, a Notice that doesn't change the health score: the homepage's header and footer have no link to one or more of these sections: Features or Services, Pricing, Compare, Resources (such as a blog or guides), and Company (such as About or Careers). The row lists the sections missing. Add a footer column or nav link for each one that fits your business. Not every business needs a Compare or Pricing page, so this is a recommendation only. When Mark can't read the homepage's header and footer, the check is skipped.
• Key page has fewer than 2 internal links pointing at it, a Warning: a pricing, features, services, solutions, products, compare, vs, or alternatives page with fewer than 2 links to it from the site's other pages. The row shows the count. Link to the page from the footer or nav and from related pages. The homepage is never flagged.
• Privacy, Terms, or Contact page is missing or broken, a Notice: the site has no Privacy page, no Terms page, or no Contact or Support page in the homepage's header or footer or among the crawled pages. A page that is linked but returns an error or has under 50 words also counts, even when another page of the same kind works. The row lists the missing kinds and each broken page. A broken page also keeps its own error issue.

Mark finds these pages by their address and link text, in English only.

AI crawler access

Each audit reads the site's robots.txt and shows, under AI crawler access on Overview, one row for each AI crawler: its vendor, its role, and what robots.txt says to it. The audit checks the home page /, and also the first blog post and the pricing page when the crawl reached them. A bot blocked only on /blog/ still shows as blocked.

The four answers:

• Allowed: a rule allows the bot, or robots.txt has a group of rules for the bot that blocks none of the checked pages.
• Blocked: a Disallow rule covers a checked page. The row quotes the rule and the User-agent group it sits in.
• No rule: nothing in robots.txt applies to the bot, which means allowed.
• Couldn't check: robots.txt answered a server error, timed out, or couldn't be fetched, twice. There's no answer either way until the next audit.

A robots.txt that answers 404 or another 4xx error counts as missing, which allows every bot. Rules are read the way the robots.txt standard (RFC 9309) reads them. A group that names the bot beats User-agent: *, the longest matching rule wins, and Allow wins a tie.

The roles:

• search: builds an assistant's search index, such as OAI-SearchBot for ChatGPT search, Claude-SearchBot, or PerplexityBot.
• user fetch: fetches a page because a person asked an assistant about it, such as ChatGPT-User, Claude-User, or Perplexity-User.
• training: collects pages for model training, such as GPTBot, ClaudeBot, or CCBot.
• control token: not a crawler, only a switch in robots.txt, such as Google-Extended or Applebot-Extended.

Only a blocked search or user-fetch bot adds an issue: robots.txt blocks AI search or user-fetch bots, a site-wide Notice in the AI readiness category that names each bot and its rule. Blocking a training crawler or a control token is a choice, so those rows read Blocked (training opt-out) and add no issue. Neither the card nor the issue changes the health score. When the AI readiness scan also flags robots.txt, the report shows Mark's row only.

The card shows what robots.txt says, not whether a bot can reach the site. A CDN, WAF, or bot manager can still block a bot that robots.txt allows, and some user-fetch bots don't read robots.txt. To see which assistants actually fetch your pages, select See what AI assistants fetch to open Performance > AI assistants.

When robots.txt contains Cloudflare's managed content, the card says so, since Cloudflare can add AI crawler rules you didn't write. A Content-Signal line, if there is one, shows as written. Audits that ran before this check existed don't show the card.

Agentic readiness (experimental)

Each audit runs Google Lighthouse's agentic browsing checks on the home page and up to two other shallow pages, through Google's PageSpeed Insights on a mobile profile. Google marks this check set as experimental: it needs Chrome 150 or later, and Google may change or add checks. The Agentic readiness card on Overview shows which Lighthouse version ran.

The card reads "N of M checks passed". M counts only checks that passed or failed. A check that doesn't apply, a check that only reports information, and a check Mark couldn't run are listed but not counted. A check passes when Lighthouse rates it 0.9 or higher, and fails if it fails on any checked page.

The checks:

• Accessibility tree: whether the page's accessibility tree is well formed, the structure AI agents read to find buttons, links and fields. A failure names each rule and the element that breaks it.
• Cumulative Layout Shift: how much the page moves while it loads. CLS comes from a single lab load, so it can vary between audits.
• llms.txt: Mark fetches /llms.txt itself with Lighthouse's rules: a Markdown file with an H1 title, at least one Markdown link, and at least 50 characters. A site with no llms.txt shows the check as not applicable, not failed.
• ai-catalog.json: whether the site's AI catalog is valid. Not applicable when the site has none.
• WebMCP (three checks): listed as Not checked yet. WebMCP is in an origin trial, and PageSpeed Insights can't run it.

Couldn't check means a fetch failed: the site or PageSpeed Insights timed out, couldn't be reached, or answered "too many requests" (429), even after one retry, or the site refused it (401 or 403, often a bot block). It never counts as a failure. For llms.txt, a 404 or 410 means the site has no file, so the check is not applicable, and a server error (5xx) after one retry is a failure, as Lighthouse reads it. When Lighthouse couldn't run at all, the card says Couldn't check in place of the count, and the llms.txt check and Mark's own checks below still run. A check passes when it passed on every page Lighthouse ran it on; the card lists any page Lighthouse couldn't run.

A failing check also appears on Issues in the Agentic readiness category, with how to fix it and a link to Google's documentation. Select the Agentic readiness tile to see only those. They don't change the health score or any other category. When Mark's llms.txt check reached a verdict, the AI readiness scan's own llms.txt issue isn't shown.

Under Mark's checks, not scored, the card reports two facts that never count toward the checks passed or any score:

• Markdown negotiation: what the home page returns when an agent asks for Markdown (Accept: text/markdown): Markdown, HTML, or another format. For Markdown, it says whether the response sends Vary: Accept, so caches keep the Markdown and HTML versions apart. It also says if asking for HTML no longer returns HTML. When the AI readiness scan flags Markdown negotiation too, the row links its report.
• Link headers: the links the home page's Link response header lists, a Markdown alternate first. A <link rel="alternate" type="text/markdown"> that is only in the page's HTML is listed apart from the header. Links to an API catalog (api-catalog) or AI catalog (ai-catalog) show as one note.

Agents get the same data from the get_site_audit tool. Audits that ran before this check existed don't show the card or the tile.

How AI crawlers read your pages

Many AI crawlers don't run JavaScript. After the crawl, the audit fetches the HTML of every page that loaded, the way such a crawler gets it, and compares it with what the browser showed. How AI crawlers read your pages, on Overview below AI crawler access, gives each page one label:

• Needs JavaScript: the HTML is a shell and the content appears only in a browser. For example, the HTML has far fewer words than the page in a browser ("38 words without JavaScript, 1,240 words in a browser"), or it carries the homepage's HTML, title, or canonical instead of the page's own. Crawlers that run no JavaScript can miss what's on the page.
• Pre-built HTML: the content is in the HTML, and the page shows it was built ahead of time. Mark says how it can tell: Vercel served it from its prerender output, it's hosted on GitHub Pages, or its generator tag names a static site generator such as Hugo, Jekyll, Gatsby, Astro, or Docusaurus.
• Server HTML: the content is in the HTML, and Mark found no sign it was pre-built. Some pre-built sites read this way, because many hosts don't say how a page was made.
• Couldn't fetch: the page didn't answer, answered with an error, or was larger than 5 MB, so there's no label. The row says why.

Pre-built HTML and server HTML are both readable to crawlers. The difference only matters when you're debugging how the site is hosted.

A Key page tag marks the homepage and pages whose address or title names pricing, plans, a comparison or alternative, a demo, a quote, contact, booking, buying, or a trial. A key page that needs JavaScript is tinted and listed first. Select a column header to sort by it, or the filter icon in the Read as header to show one label. Fix those first: pricing and other pages that close deals, then landing pages for the buyers you target, then the blog.

To fix a page that needs JavaScript, serve its content in the HTML:

• publish a static HTML version of the page;
• turn on server rendering or static rendering in the tool the site is built with; or
• host the page on Mark.

Run the audit again after you publish a fix. Each audit labels every page from scratch.

Some sites use dynamic rendering: a service such as Prerender.io sends AI bots like GPTBot, ClaudeBot, and PerplexityBot a pre-rendered page and everyone else the JavaScript version. Mark fetches as itself, not as one of those bots, so it gets the JavaScript version and reports Needs JavaScript. Google calls dynamic rendering a workaround, not a long-term fix, so serving the content in the HTML is still the fix.

The label doesn't change the health score. The blank page alert still comes from the same few sample pages as before. Audits that ran before this check existed don't show the section.

Internal link opportunities

When Search Console is connected, the audit suggests links between your own pages. It reads 28 days of Search Console data, ending 3 days ago since Google's newest days are still filling in, and looks for two kinds of page:

• Strong: at least 20 clicks, at an average position of 10 or better.
• Stuck: an average position from 11 to 30, with at least 100 impressions. These are just past the first page of results.

It pairs a strong page with a stuck page only when they're related: the strong page ranks for one of the stuck page's top five searches, or the two sit in the same section of the site (the same first part of the address) and their titles share at least two words. A strong page that already links to the stuck page is left out.

Internal link opportunities, on Overview, lists up to five pairs. Each shows the page to link from, the page to link to, the link text to use (the shared search, when there is one), and why the pair makes sense. Once a stuck page holds a top 10 position for about 4 weeks, move the link to another stuck page.

These are suggestions only. Mark doesn't change your site; you add the links yourself.

If Search Console isn't connected, has no property picked, or its property is for a different domain, the section says so instead. When the audit finds no pairs, the section doesn't show. Audits that ran before this section existed don't show it either.

Pages AI assistants can't find

AI assistants often ask for pages that don't exist on your site: old addresses from an earlier version of it, or addresses they made up. A crawler that gets a 404 learns nothing about you. When PostHog is connected, Mark finds these pages for your primary site.

Once a day, Mark looks at the pages assistants fetched in the last 7 days, from the AI assistant traffic it already reads. A page counts when assistants fetched it at least 3 times, on at least 2 different days or by at least 2 different assistants. Mark then requests each of those pages once, up to 20 a day, without following redirects. Fonts, images, styles, and scripts are left out.

Pages AI assistants can't find, on Overview below Internal link opportunities, lists each page that answered 404. Each shows the page, its hits in the last 7 days, the assistants that asked for it, and what to do:

• Add a 301 redirect to a page from your latest finished audit, when exactly one page has every word in the last part of the missing address, in the last part of its own address or in its title. Mark needs at least two words, or one model code such as SF-2200 (three or more digits, so page-2 doesn't count), and ignores bare numbers. The item names the words it matched on.
• Publish this file, for robots.txt, a sitemap, llms.txt, or an address under /.well-known/. Assistants ask for these files by name, so a redirect can't stand in for them.
• Fine as a 404, when no page matches, or more than one does. Redirecting to an unrelated page counts as a soft 404, which is worse than an honest 404.
• Run a site audit to get a redirect suggestion, when the site has no finished audit yet.

Mark only recommends. You add redirects on your own server or website platform. AI assistant vendors don't document whether their crawlers follow redirects, so watch the page's hits after you add one.

A page leaves the list on its own when it answers with a page or a redirect, or when assistants stop asking for it often enough. Dismiss for 90 days hides one page. If it still answers 404 after 90 days, it comes back.

The section ends with one tip for the whole site: keep a helpful 404 page that links to your main sections and still answers with a 404 status.

The section shows only on your primary site, only when PostHog is connected, and only when a page answered 404. A check that times out, can't connect, or gets a server error isn't listed. Mark tries again the next day.

Check AI readiness

The AI readiness tile has a Check now button. It runs a new AI readiness scan and rescores the report. When it finishes, the tile says "Updated just now." If the scan can't run, it says "Could not check right now. Try again in a few minutes." and keeps the last results.

A site that has an AI readiness scan but no audit yet shows the AI readiness tile and its issues on their own. Select Run audit to add the crawl.

When an audit doesn't finish

If the crawl fails, the report says The audit didn't finish and shows why, for example when the site's robots.txt blocks the crawler, the site can't be reached, or the crawl timed out. Fix the cause if there is one, then select Try again to run a new audit.

While a new audit runs, or after one fails, the last finished audit stays below it on Overview under Last finished audit, with the date it finished. Select it to open it. Issues shows that audit's lists, marked "From the last finished audit."

Audits that ran before site-wide checks existed show the issues they found on each page, without site-wide rows.