# Site audit

> Run an audit of a website or schedule one weekly, read its health score by category and its action plan, and work through its issues by check or by page.

Source: https://docs.use-mark.com/docs/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 &#x2A;*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.
