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 Analysis > Website in the sidebar to find the Site audit report.

Run an audit

1. Select Analysis > Website. It opens your primary site. If you have more than one site, select the site's name at the top to switch.
2. In Site audit, select Run audit. After the first audit the button reads Run audit again.

While the audit runs, the report 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.

The report header shows when the audit finished, how many pages it crawled, and when AI readiness was last scanned.

Run audits on a schedule

Each audit is a paid crawl, so a site starts on Manual and audits only when you select Run audit. To audit it once a week instead:

1. In Site audit, under Schedule, choose one:
   • Manual: only when you click Run audit
   • Weekly: runs a paid audit 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, since every retry is another paid crawl. Select Try again to rerun it yourself.

Read the health score

The health score runs from 0 to 100. Next to it are seven category tiles, each with its own score and a count of issues per severity:

• Crawlability & indexing: broken pages, redirects, and canonicals.
• 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 issues from the site's AI readiness scan.

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. A category with nothing checked shows n/a and doesn't count toward the health score.

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.

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 jump to its row in By issue and open it. 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.

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.
• 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, and judges only pages with fewer than 400 words in total or in the main text. 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.

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 list has 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.

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. Site-wide issues aren't in this view.

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. 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 the report. 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 jump to its row.

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.

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.

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 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.

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 under Last finished audit, with the date it finished. Select it to open it.

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