Nosy Bat issue library
340+ named checks across 29 families, from response codes to accessibility, each with what it means and how to fix it. Issues are problems to fix, warnings need a look, opportunities are improvements. Checks marked “Needs rendering” run on pages crawled with JavaScript rendering on; “Needs a Lighthouse run” checks use the page’s PageSpeed Insights results.
A URL on the site answers with a 4xx status, usually 404 Not Found or 410 Gone. Visitors and crawlers who follow a link to it hit a dead end.
How to fix. Restore the page, or 301-redirect the URL to its closest live equivalent, then update the internal links that point at it.
A URL on the site answers with a 5xx status. The server failed to produce the page; search engines retry, then drop URLs that keep failing.
How to fix. Check the server and application logs for this URL at the crawl time, fix the failing code path or capacity issue, and re-crawl.
The page links to another site's URL that answers with a 4xx status. A broken outbound link is a dead end for readers and a quality signal for search engines. The evidence shows how many, a sample URL and how many pages of your site it is found on.
How to fix. Update the link to the resource's new address, link to an archived or alternative source, or remove it.
The page links to another site's URL that answered with a 5xx status during the crawl. It may be a temporary outage on their side. The evidence shows a sample URL and how many pages of your site it is found on.
How to fix. Re-check the link later. If it keeps failing, replace it with a working source or remove it.
The request produced no HTTP response at all: a timeout, a DNS failure, a refused connection or too many redirects.
How to fix. Load the URL yourself to confirm. Check DNS, firewall or bot-protection rules that may block crawlers, and how long the server takes to answer.
The crawled URL redirects to another URL. Redirects are fine for moved content, but each one costs a request and dilutes crawl budget when internal links keep pointing at them.
How to fix. Keep the redirect for external visitors, but point internal links straight at the final URL.
Reaching the final URL takes more than one redirect hop. Every hop adds latency, and search engines stop following long chains.
How to fix. Redirect the original URL straight to the final destination in a single hop, and update links to point at the final URL.
The URL's redirects lead back to a URL already in the chain, so the page can never load.
How to fix. Find the rule that sends the last URL in the loop back to the first (often HTTP/HTTPS or trailing-slash rules fighting) and break the cycle.
The page uses <meta http-equiv="refresh"> to send visitors elsewhere. Search engines treat it as a weak redirect, and it disorients screen-reader users.
How to fix. Replace the meta refresh with a server-side 301 (permanent) or 302 (temporary) redirect.
The URL redirects, and the destination answers with a 4xx or 5xx status. The redirect sends visitors to a dead end.
How to fix. Point the redirect at a live page, or fix the destination.
robots.txt disallows this URL, so it was recorded but not fetched. Search engines will not crawl it either, though they can still index the bare URL if other pages link to it.
How to fix. If the page should rank, remove the Disallow rule that matches it. If it should stay out of search, use noindex instead and let it be crawled.
Other pages on the site link to this URL, which redirects. Each click costs an extra request and passes link signals through a hop.
How to fix. Update those internal links to point straight at the redirect's destination.
The URL path contains characters outside ASCII (accented letters, symbols, other scripts). Browsers show them fine, but they are percent-encoded when copied, shared or logged, which makes the URL long and unreadable.
How to fix. Use plain ASCII slugs (e.g. "cafe" rather than "café") for new URLs. Change existing ones only with a 301 redirect from the old address.
The URL path uses underscores. Search engines treat hyphens as word separators but may read underscores as joining words, so "red_shoes" can be read as one word.
How to fix. Use hyphens in new URLs. Renaming existing URLs is rarely worth it on its own; if you do, 301-redirect the old ones.
The URL path contains uppercase letters. Paths are case-sensitive on most servers, so /Page and /page can be two URLs with the same content.
How to fix. Use lowercase paths, and 301-redirect uppercase variants to the lowercase URL.
The URL carries query parameters. Parameters for sorting, filtering or tracking can multiply one page into many crawlable URLs.
How to fix. Keep parameters out of internal links where a clean path works, and set a canonical to the parameter-free version on filtered or sorted views.
The URL is longer than 115 characters. Long URLs are truncated in search results, hard to share and often a sign of deep nesting or stacked parameters.
How to fix. Shorten the slug and flatten unnecessary folder levels for new pages. Redirect existing long URLs only when you restructure.
The URL path contains a double slash (//). It usually comes from a template joining paths badly, and can create duplicate URLs for one page.
How to fix. Fix the template or link that produces the double slash, and 301-redirect the variant to the single-slash URL.
A segment repeats in the URL path (e.g. /shop/shoes/shop/shoes). This is typically a relative-link bug that lets crawlers generate endless URLs.
How to fix. Make the offending links absolute or root-relative (starting with /), and return 404 or redirect for the generated paths.
The URL path contains an encoded space (%20 or +). Spaces break when URLs are pasted into emails or chat, and look untidy in search results.
How to fix. Use hyphens instead of spaces in file and page names, and redirect the old URLs.
The URL looks like a site-search results page (a parameter such as q= or search=). Search engines advise against indexing internal search results: they are thin and endless.
How to fix. Add noindex to search results pages and avoid linking to them from crawlable navigation. Blocking them in robots.txt also stops crawl waste.
This URL answers 200, but its canonical is the same path with the trailing slash added or removed. Both variants are live, so links and signals are split between two URLs.
How to fix. Pick one form, 301-redirect the other to it, and link internally only to the chosen form.
The page has no <title>, or only an empty one. The title is the headline of a search result and the text of a browser tab; without it, search engines write their own.
How to fix. Add a unique, descriptive <title> inside <head> that names what the page offers.
Another crawled page has exactly the same title. Identical titles make pages hard to tell apart in search results and suggest duplicate or templated content.
How to fix. Give each page a title that describes its own content. If the pages really are duplicates, consolidate them or set a canonical.
The title is longer than 60 characters, about where search results start to cut titles off.
How to fix. Put the most important words first and trim the rest so the meaning survives truncation.
The title is longer than 70 characters and will almost certainly be truncated in search results, losing whatever comes after the cut.
How to fix. Shorten the title to under 60 characters. Drop filler, repeated keywords and long brand suffixes first.
The title is shorter than 30 characters. Short titles often miss the words people search for and leave space in the result unused.
How to fix. Expand the title with the page's main topic and a distinguishing detail, staying under 60 characters.
The title's estimated width in a desktop search result is over 561 pixels, the point at which titles are usually truncated. Wide characters (W, M, capitals) hit the limit before the character count does.
How to fix. Shorten the title or use fewer capitals and wide characters until it fits.
The title's estimated width in a desktop search result is under 200 pixels: a very short headline that uses little of the space available.
How to fix. Add descriptive words that match what people search for.
The title is identical to the page's first H1. That is not wrong, but it misses a chance to use a second phrasing of the topic.
How to fix. Consider writing the title for the search result and the H1 for the reader already on the page, with different wording.
The page has more than one <title>. Search engines use one of them, not necessarily the one you intended.
How to fix. Keep a single <title> in <head>. Look for a template or plugin adding a second one.
A <title> element sits in the <body>. Search engines expect it in <head> and may ignore it where it is.
How to fix. Move the <title> into <head>. If a script or widget writes it into the body, fix that output.
The page has no meta description, or an empty one. Search engines then build the snippet from page text, which is often a menu or cookie notice.
How to fix. Add a <meta name="description"> in <head>: one or two sentences, 70–155 characters, saying what the page offers and why to click.
Another crawled page has exactly the same meta description. Repeated snippets make results from your site look interchangeable.
How to fix. Write a description for each page from its own content. For large templated sections, generate it from page-specific fields.
The description is longer than 155 characters, so search results will usually cut it off mid-sentence.
How to fix. Lead with the key message and trim to under 155 characters.
The description is shorter than 70 characters. A very short snippet wastes space that could sell the click.
How to fix. Expand it with what the page offers and a reason to choose it, staying under 155 characters.
The description's estimated width in a desktop search result is over 985 pixels, about where snippets are truncated.
How to fix. Shorten the description until it fits; wide characters and capitals use space fastest.
The page has more than one meta description tag. Search engines pick one, not necessarily the right one.
How to fix. Keep one description tag. Check for a theme and an SEO plugin both writing one.
A meta description tag sits in the <body>, where search engines may ignore it.
How to fix. Move the tag into <head>, or fix the template or script that writes it into the body.
The page carries a <meta name="keywords"> tag. Google and Bing ignore it for ranking; its only effect is publishing your target keywords to competitors.
How to fix. Remove the tag from the template or SEO plugin settings.
The page has no <h1>. The main heading tells readers and search engines what the page is about, and screen-reader users jump to it first.
How to fix. Add one <h1> near the top of the main content that names the page's topic.
Another crawled page uses exactly the same H1. Identical main headings make pages look interchangeable.
How to fix. Make each H1 describe its own page; if the pages are duplicates, consolidate them.
An H1 is longer than 70 characters. Long main headings are hard to scan and often carry a paragraph's worth of keywords.
How to fix. Shorten the heading to the essential topic and move detail into the opening paragraph.
The page has more than one <h1>. It is valid HTML, but a single main heading gives the clearest outline.
How to fix. Keep one H1 for the main topic and turn the others into H2s. Check for a logo or widget wrapped in an H1.
This page's H1 is the exact title of a different page on the site. The two pages may be competing for the same query.
How to fix. Differentiate the heading, or merge the pages if they cover the same thing.
An <h1> has no text, often an image without alt text or a heading left behind by a template.
How to fix. Give the heading text, or give the image inside it alt text that names the page.
The page has no <h2>. Section headings break content into scannable parts and give search engines and screen readers an outline.
How to fix. Add H2s for the main sections of the content. Short pages with one idea may not need any.
This page's first H2 is the same as on other crawled pages, usually a template heading ("Related products", "Contact us") in the first slot.
How to fix. Make the first section heading specific to the page, or move shared template headings below the page's own sections.
An H2 is longer than 70 characters, which reads like a sentence rather than a heading.
How to fix. Shorten the heading and move the detail into the section's first paragraph.
The same H2 text appears more than once on the page, so the outline has two sections with the same name.
How to fix. Rename the sections so each heading says what is different about it.
An <h3> appears before the first <h2>. Skipping a level breaks the document outline that screen-reader users navigate by.
How to fix. Use headings in order (H1, then H2, then H3), and style them with CSS rather than picking a level for its size.
An <h2> has no text, usually a leftover from a template or an icon-only heading.
How to fix. Give the heading text or remove the empty element.
The page has fewer than 200 words of visible text. Thin pages rarely answer a query well enough to rank, unless their job is something else (a contact form, a gallery).
How to fix. Expand pages meant to rank with useful, specific content. Leave utility pages alone, or keep them out of the index.
Another crawled page has exactly the same visible text. Search engines pick one version to show and may pick the wrong one.
How to fix. Consolidate the pages with a 301 redirect, or point the copies at the main version with rel=canonical.
Another crawled page's text is almost identical to this one (a similarity fingerprint within 3 bits). Typical causes: location or product variants with only a word or two changed.
How to fix. Give each page enough unique content to stand alone, or canonicalise the variants to one main page.
The English text scores below 50 on the Flesch reading-ease scale: long sentences and long words. That is college level, harder than most visitors want to read.
How to fix. Shorten sentences, prefer common words, and break long paragraphs up with headings and lists.
The page contains placeholder text such as "lorem ipsum", "coming soon" or "under construction". It reads as unfinished to visitors and search engines.
How to fix. Replace the placeholder with real content, or keep the page out of the index until it is ready.
The page answers 200 OK but looks like an error page: a "not found" title, or almost no content. Search engines treat it as a 404 and may also distrust the site's real 200s.
How to fix. Return a real 404 or 410 status for missing pages, or add real content if the page should exist.
Visible text is under 10% of the HTML. The page is mostly markup, scripts and inline styles, which slows it down without adding anything to read.
How to fix. Move inline scripts and styles into cached files, trim unused markup, and check the page has real content.
The <html> element has no lang attribute. Screen readers then guess the pronunciation, and browsers cannot offer the right translation.
How to fix. Set the page language on the root element, e.g. <html lang="en"> or <html lang="fr-CA">.
Neither the Content-Type header nor the HTML declares a character encoding. Browsers then guess, and accented characters can come out garbled.
How to fix. Send charset=utf-8 in the Content-Type header, and add <meta charset="utf-8"> as the first element in <head>.
The page declares an encoding other than UTF-8 (e.g. ISO-8859-1 or Windows-1252). UTF-8 is the web standard; other encodings break on characters they cannot represent.
How to fix. Save templates and content as UTF-8 and declare charset=utf-8 in the header and <meta charset>.
This page's text means nearly the same as another page's (cosine similarity of their embeddings 0.95 or more), even if the wording differs. Search engines pick one and may ignore the other, and the two compete for the same queries. The evidence shows the other URL and the score.
How to fix. Merge the two pages and 301 the weaker one to the stronger, or rewrite one so each answers a distinct question; a canonical works when both must stay.
This page's text is among the 5 % furthest from what the site as a whole is about (distance from the average of all embedded pages). It may be stray, outdated or thin content that dilutes the site's topical focus.
How to fix. Check whether the page belongs: bring it closer to the site's subject, link it into a relevant section, or remove or noindex it.
An <img> has no alt attribute at all. Screen readers then read out the file name, and search engines lose the image's description. An empty alt="" is fine for decorative images; a missing one is not.
How to fix. Add alt text that says what the image shows or does. Use alt="" only for purely decorative images.
An image's alt text is longer than 100 characters. Long alt text is tedious to listen to and often stuffed with keywords.
How to fix. Describe the image in one short phrase. Put longer explanations in a caption or the surrounding text.
An image has no width or height attribute, so the browser cannot reserve its space and the layout jumps when it loads (Cumulative Layout Shift).
How to fix. Add width and height attributes with the image's intrinsic size; CSS can still scale it responsively.
An image on the page answers with an error status, so visitors see a broken-image icon or an empty gap.
How to fix. Fix the image's path, restore the file, or remove the reference.
An image on the page weighs more than 100 KB. Heavy images are the most common reason pages load slowly on mobile.
How to fix. Resize the image to the size it is displayed at, compress it, and serve WebP or AVIF.
An image's alt text just repeats its file name (e.g. "IMG 0423" or "hero banner"), which describes nothing to a screen-reader user.
How to fix. Write alt text that describes what the image shows.
The page loads more than 50 images. Even lazy-loaded, that is a lot of requests and decoding work, especially on mobile.
How to fix. Paginate long galleries, use thumbnails, and check for repeated decorative images that could be CSS.
Images further down the page (after the first three) load immediately instead of when the visitor scrolls to them, competing with the content on screen.
How to fix. Add loading="lazy" to images below the fold.
The first image on the page has loading="lazy". If it is the hero or main image, lazy-loading delays the Largest Contentful Paint.
How to fix. Remove loading="lazy" from images visible on first load; consider fetchpriority="high" on the main image.
An image 400 pixels or wider (or with no declared width) offers a single file for every screen, so phones download the desktop-size image.
How to fix. Provide srcset with several widths and a sizes attribute, or use your framework's responsive image component.
A JPEG, PNG or GIF is served with no WebP or AVIF alternative. Modern formats are typically 25–50% smaller at the same quality.
How to fix. Serve WebP or AVIF, either directly or through a <picture> element with a JPEG/PNG fallback.
The page declares no canonical URL, in the HTML or a Link header. Without one, parameter and tracking variants of the page compete with it.
How to fix. Add <link rel="canonical" href="…"> in <head>, usually pointing at the page's own clean URL.
The page's canonical points at a different URL, so it asks search engines to index that URL instead of this one. That is right for duplicates and variants, and a mistake anywhere else.
How to fix. Check the target is the intended main version. If this page should rank on its own, make the canonical self-referencing.
The page declares more than one rel=canonical. Search engines may ignore all of them when they disagree.
How to fix. Keep one canonical. Look for a theme and a plugin (or a CMS and a CDN) each adding one.
The canonical target redirects elsewhere. It sends mixed signals, and search engines may disregard it.
How to fix. Point the canonical straight at the final URL the redirect leads to.
The canonical target answers 4xx or 5xx. You are asking search engines to index a page that does not work.
How to fix. Point the canonical at a live page, usually this page's own URL.
The canonical target carries noindex. One says "index that page", the other says "do not index it", so neither may end up indexed.
How to fix. Canonicalise to an indexable page, or remove noindex from the target if it should be indexed.
The canonical is a relative URL (e.g. /page). It is allowed, but a base-tag or protocol mistake turns it into the wrong address.
How to fix. Use the full absolute URL, including https:// and the host.
The Link response header and the HTML declare different canonical URLs. Search engines may ignore both.
How to fix. Declare the canonical in one place, or make both point at the same URL.
A rel=canonical link sits in the <body>. Google ignores canonicals outside <head>.
How to fix. Move the canonical into <head>, or fix the script that injects it into the body.
This HTTPS page's canonical points at an http:// URL, asking search engines to prefer the insecure version.
How to fix. Change the canonical to the https:// URL.
The page tells search engines not to index it (meta robots or X-Robots-Tag). Right for thank-you pages, internal search and staging; costly when it is on a page you want found.
How to fix. If the page should appear in search, remove noindex from the meta tag and the X-Robots-Tag header. Otherwise, nothing to do.
The page tells search engines not to follow any of its links, so none of them pass signals or lead to discovery.
How to fix. Remove page-level nofollow unless you have a specific reason. To discount individual links, put rel="nofollow" on those links instead.
The page uses the "none" directive, shorthand for noindex and nofollow together.
How to fix. Check this is intended. For a page that should rank, remove the directive.
The page asks search engines not to keep a cached copy. It does not affect ranking.
How to fix. Usually fine as is. Remove it if you have no reason to hide cached copies.
The page forbids text snippets and video previews in search results, which usually lowers click-through. It also keeps the page's text out of AI overviews.
How to fix. Remove nosnippet unless the content must not be quoted. Use data-nosnippet on specific passages instead.
The page limits how many characters search engines may show in a snippet. A low limit shortens or removes the description shown in results.
How to fix. Check the limit is deliberate; max-snippet:-1 means no limit.
The page asks search engines not to index its images, so they will not appear in image search from this page.
How to fix. Remove it if image search traffic is useful to you.
The page asks search engines not to offer a translation of it in results.
How to fix. Remove it unless translation would genuinely mislead readers.
The page carries an expiry date after which search engines should drop it from results.
How to fix. Check the date is right and the page really should disappear then, e.g. an event or offer page.
The page says noindex and also names another URL as its canonical. Google warns the two signals conflict, and the canonical may be ignored.
How to fix. Use one: a canonical for a duplicate that should pass its signals, or noindex for a page that should simply stay out of search.
The page is listed in the XML sitemap but carries noindex. The sitemap says "index this" and the page says "do not".
How to fix. Remove noindex pages from the sitemap, or remove noindex if the page belongs in search.
A meta robots or googlebot tag sits in the <body>, where search engines may not honour it.
How to fix. Move the tag into <head>, or fix the script that injects it into the body.
The X-Robots-Tag header and the meta robots tag give different index or follow instructions. Search engines apply the most restrictive one, which may not be the one you meant.
How to fix. Set the directive in one place, or make the header and the tag say the same thing.
The page links to more than 100 distinct external URLs. Link-heavy pages look like directories and spread readers' attention thin.
How to fix. Keep the links that help the reader and remove or paginate the rest.
The page links to more than 500 distinct internal URLs, usually a mega-menu or a footer repeated on every page. Each link then carries very little weight.
How to fix. Trim navigation to the pages that matter and move long lists into hub pages.
The page links to no other page on the site. It is a dead end for visitors and for crawlers following links.
How to fix. Add navigation and contextual links to related pages. Check the links are real <a href> elements, not script-only.
Every internal link to this page is rel="nofollow", so it receives no internal link signals.
How to fix. Remove nofollow from internal links to pages you want to rank.
Links use generic text such as "click here" or "read more". It tells search engines nothing about the target, and screen-reader users listing links hear a column of identical phrases.
How to fix. Make the link text describe the destination, e.g. "read our pricing guide" instead of "read more".
The page links to localhost or a loopback address, a leftover from development that is broken for every visitor.
How to fix. Replace the links with production URLs, or root-relative paths.
The page marks links to other pages on the same site rel="nofollow", withholding link signals from your own pages.
How to fix. Remove nofollow from internal links. To keep a page out of search, use noindex on that page instead.
Pages link to URLs on this site that redirect. Each click costs an extra hop.
How to fix. Update the links to point straight at the redirect destination.
The page links internally to URLs with query parameters. Parameter variants can multiply crawlable URLs and split signals.
How to fix. Link to the clean URL wherever the parameter is not needed, and canonicalise parameter variants.
Just one page on the site links here. Pages with few internal links are crawled less and rank less.
How to fix. Link to the page from related content, hub pages or navigation.
The page is more than three clicks from the start URL. Deep pages are crawled less often and are hard for visitors to find.
How to fix. Add links from higher-level pages, hubs or navigation to bring it closer to the homepage.
The page is listed in the sitemap but no crawled page links to it. Search engines may find it through the sitemap, but it receives no internal link signals.
How to fix. Link to it from relevant pages, or remove it from the sitemap if it should not be live.
Some outbound links point at URLs that redirect. They work, but the destination may have moved for good.
How to fix. Update the links to the final destination URLs.
A link's text is longer than 100 characters, usually a whole sentence or a block wrapped in a link.
How to fix. Link a short, descriptive phrase rather than the whole sentence or card.
The page links to http:// URLs. Visitors may be shown an insecure-site warning, or a redirect hop at best.
How to fix. Change the links to https://. For your own site, update templates and content to use HTTPS URLs.
This indexable page is linked from the site, but its Link Score (internal PageRank, 0–100) is in the crawl's bottom 10 %. Few, weak or deep internal links point at it, so search engines see it as one of the least important pages on the site.
How to fix. If the page matters, link to it from stronger pages: the home page, hubs and category pages, or related articles. If it does not, consider merging it into a stronger page.
The sitemap lists URLs this crawl never reached, because the URL limit or time limit stopped it, or because robots.txt or scope rules kept them out.
How to fix. Raise the crawl limit or check those URLs. A sitemap should list only live, indexable pages on the site.
This page answers 200, is indexable and self-canonical, but the sitemap does not list it. Search engines may find it later, or not at all.
How to fix. Add the page to the sitemap, or check your sitemap generator includes this section of the site.
The sitemap lists a URL that is noindex or canonicalised to another page. A sitemap should list only the URLs you want indexed.
How to fix. Remove the URL from the sitemap, or make the page indexable and self-canonical.
The sitemap lists a URL that redirects. Search engines are asked to crawl an address that is not the real page.
How to fix. List the final destination URL instead of the redirecting one.
The sitemap lists a URL that answers 4xx or 5xx. Too many errors make search engines trust the sitemap less.
How to fix. Remove dead URLs from the sitemap, or restore the pages.
The crawl found no XML sitemap, neither declared in robots.txt nor at /sitemap.xml. Search engines then rely on links alone to discover pages.
How to fix. Publish an XML sitemap of your indexable pages and declare it in robots.txt with a Sitemap: line.
A sitemap file lists more than 50,000 URLs, the protocol's limit per file. Search engines may reject it.
How to fix. Split it into several files of at most 50,000 URLs (and 50 MB uncompressed) and list them in a sitemap index.
A sitemap exists, but robots.txt has no Sitemap: line pointing to it. Declaring it helps every search engine find it, not only those you submit it to.
How to fix. Add Sitemap: https://your-site/sitemap.xml to robots.txt.
The page is served over plain HTTP, without encryption. Browsers label it "Not secure", and HTTPS is a ranking signal.
How to fix. Serve the site over HTTPS and 301-redirect every http:// URL to its https:// equivalent.
This HTTPS page loads resources (images, scripts, styles, frames) over http://. Browsers block or warn about them, which can break the page.
How to fix. Load every resource over https://, or from your own domain with relative URLs.
A form on the page submits to an http:// URL, so whatever the visitor types travels unencrypted. Browsers warn before submitting it.
How to fix. Point the form's action at an https:// URL.
A link opens another site in a new tab without rel="noopener". Older browsers let the opened page control yours ("reverse tabnabbing").
How to fix. Add rel="noopener" (or rel="noopener noreferrer") to links with target="_blank".
The HTTPS response has no Strict-Transport-Security header, so a visitor's first request can still be downgraded to HTTP.
How to fix. Send Strict-Transport-Security: max-age=31536000; includeSubDomains once the whole site works over HTTPS.
The response has no Content-Security-Policy header, the main browser defence against injected scripts.
How to fix. Add a Content-Security-Policy. Start in report-only mode to see what a strict policy would block.
The response lacks X-Content-Type-Options: nosniff, so browsers may guess a file's type and run something that should not run.
How to fix. Send X-Content-Type-Options: nosniff on every response.
Neither X-Frame-Options nor a CSP frame-ancestors rule stops other sites from framing this page (clickjacking).
How to fix. Send X-Frame-Options: SAMEORIGIN, or Content-Security-Policy: frame-ancestors 'self'.
The response sets no Referrer-Policy, leaving how much of the URL is shared with other sites to the browser default.
How to fix. Send Referrer-Policy: strict-origin-when-cross-origin, or a stricter policy.
The page loads resources with //host/path URLs. On HTTPS they work, but the pattern is obsolete and loads over HTTP wherever the page itself is HTTP.
How to fix. Use explicit https:// URLs.
The page is HTML, but the Content-Type header is missing or names another type. Browsers and crawlers may not render it as a web page.
How to fix. Send Content-Type: text/html; charset=utf-8 for HTML pages.
This page names an alternate that does not name it back. Hreflang must be reciprocal; search engines ignore one-way annotations.
How to fix. Make every page in a language set list every other page in the set, itself included.
An alternate is annotated as one language, but that page's own lang attribute declares another. One of the two is wrong.
How to fix. Check which language the target page is really in, then fix its lang attribute or the hreflang value.
An hreflang alternate redirects or returns an error. Search engines drop annotations to URLs that are not live.
How to fix. Point the annotation at the final live URL of the alternate.
An hreflang alternate is not reachable through the site's links; only the annotation points to it.
How to fix. Link to language versions visibly, e.g. with a language switcher, so visitors and crawlers can reach them.
The page lists alternates but not itself. Each page in a set should include an hreflang annotation for its own URL.
How to fix. Add an hreflang entry for this page's own language pointing at its own URL.
An alternate's URL is not that page's canonical. Search engines may ignore annotations to URLs they do not index.
How to fix. Use each alternate's canonical URL in hreflang.
An hreflang value is not a valid ISO 639-1 language code, optionally followed by an ISO 3166-1 region. Common mistakes: "en-uk" instead of "en-gb", or a region on its own.
How to fix. Use language-region values such as en-gb, fr-ca or es-419, or x-default for the fallback page.
The same hreflang value is assigned to more than one URL, so search engines cannot tell which one to show.
How to fix. Keep one URL per language-region value.
The page has hreflang annotations but no x-default, the page shown to visitors whose language matches none of the alternates.
How to fix. Add an hreflang="x-default" entry, usually pointing at a language selector or the main-market page.
Hreflang <link> elements sit in the <body>, where search engines do not read them.
How to fix. Move the annotations into <head>, or declare them in the XML sitemap instead.
An alternate carries noindex, so it cannot appear in search for its language however it is annotated.
How to fix. Remove noindex from the alternate, or remove it from the hreflang set.
The crawl found pages in more than one language, but this page has no hreflang annotations, so search engines must guess which version to show to whom.
How to fix. Annotate each page with its language alternates (and x-default), in <head>, a Link header or the sitemap.
A rel="next" or rel="prev" link points at a page that redirects or errors, so the series is broken at that step.
How to fix. Point pagination links at live pages, and update them when a series gets shorter.
The pages' rel="next" and rel="prev" links do not agree: page 2 says next is page 3, but page 3 does not say prev is page 2.
How to fix. Make every next/prev pair reciprocal, usually by generating both from the same page number in the template.
The page declares a rel="next" or rel="prev" URL that no visible link on the page points to. Crawlers that ignore the tags cannot reach the next page.
How to fix. Add ordinary <a href> links to the previous and next pages, e.g. in a pager.
The page declares more than one rel="next" or rel="prev" link, so the series has no single order.
How to fix. Keep one next and one prev per page.
rel="next"/"prev" <link> elements sit in the <body>, where they are not read.
How to fix. Move the <link> elements into <head>.
A later page in a series (it has a rel="prev") names another URL, typically page 1, as its canonical. Search engines may then never index the items listed on pages 2 and beyond.
How to fix. Give each page in the series a self-referencing canonical, or offer a view-all page and canonicalise to that.
A <script type="application/ld+json"> block is not valid JSON, so search engines ignore all of it. The usual culprits: a trailing comma, an unescaped quote, a template variable left empty.
How to fix. Validate the block with a JSON linter or the Rich Results Test, and fix the template that produces it.
The page has microdata that cannot be read as items: an itemscope with no itemtype, or itemprop attributes outside any itemscope.
How to fix. Give every itemscope an itemtype from schema.org and keep each itemprop inside its item's itemscope. Or switch to JSON-LD.
The page has no JSON-LD or microdata. Structured data helps search engines and AI assistants understand what the page describes, such as a business, product, article or event.
How to fix. Add JSON-LD for the page's main entity. At minimum, Organization or LocalBusiness on the homepage and the matching type on content pages.
An item uses a vocabulary other than schema.org (e.g. the retired data-vocabulary.org). Search engines only support schema.org.
How to fix. Rewrite the markup with schema.org types and a "@context": "https://schema.org";.
Two or more JSON-LD blocks on the page are identical, usually a theme and a plugin both emitting the same markup.
How to fix. Output each block once; disable the duplicate source.
A Organization item lacks properties it must have (name, url). Without them the item is not eligible for Organization rich results.
How to fix. Add the missing properties to the Organization markup. Google's structured data documentation for Organization lists them; test the page with the Rich Results Test.
A Organization item lacks properties that are optional but recommended (logo, sameAs, contactPoint). They make the item more complete for search engines and AI assistants.
How to fix. Add the recommended properties you can fill truthfully. Google's structured data documentation for Organization describes each one.
A LocalBusiness item lacks properties it must have (name, address). Without them the item is not eligible for LocalBusiness rich results.
How to fix. Add the missing properties to the LocalBusiness markup. Google's structured data documentation for LocalBusiness lists them; test the page with the Rich Results Test.
A LocalBusiness item lacks properties that are optional but recommended (telephone, openingHoursSpecification, geo, url, image). They make the item more complete for search engines and AI assistants.
How to fix. Add the recommended properties you can fill truthfully. Google's structured data documentation for LocalBusiness describes each one.
A Product item lacks properties it must have (name, offers). Without them the item is not eligible for Product rich results.
How to fix. Add the missing properties to the Product markup. Google's structured data documentation for Product lists them; test the page with the Rich Results Test.
A Product item lacks properties that are optional but recommended (image, description, brand, sku, aggregateRating). They make the item more complete for search engines and AI assistants.
How to fix. Add the recommended properties you can fill truthfully. Google's structured data documentation for Product describes each one.
A Article item lacks properties it must have (headline, author, datePublished). Without them the item is not eligible for Article rich results.
How to fix. Add the missing properties to the Article markup. Google's structured data documentation for Article lists them; test the page with the Rich Results Test.
A Article item lacks properties that are optional but recommended (image, dateModified, publisher). They make the item more complete for search engines and AI assistants.
How to fix. Add the recommended properties you can fill truthfully. Google's structured data documentation for Article describes each one.
A FAQPage item lacks properties it must have (mainEntity). Without them the item is not eligible for FAQPage rich results.
How to fix. Add the missing properties to the FAQPage markup. Google's structured data documentation for FAQPage lists them; test the page with the Rich Results Test.
A BreadcrumbList item lacks properties it must have (itemListElement). Without them the item is not eligible for BreadcrumbList rich results.
How to fix. Add the missing properties to the BreadcrumbList markup. Google's structured data documentation for BreadcrumbList lists them; test the page with the Rich Results Test.
A WebSite item lacks properties it must have (name, url). Without them the item is not eligible for WebSite rich results.
How to fix. Add the missing properties to the WebSite markup. Google's structured data documentation for WebSite lists them; test the page with the Rich Results Test.
A WebSite item lacks properties that are optional but recommended (alternateName). They make the item more complete for search engines and AI assistants.
How to fix. Add the recommended properties you can fill truthfully. Google's structured data documentation for WebSite describes each one.
A Event item lacks properties it must have (name, startDate, location). Without them the item is not eligible for Event rich results.
How to fix. Add the missing properties to the Event markup. Google's structured data documentation for Event lists them; test the page with the Rich Results Test.
A Event item lacks properties that are optional but recommended (description, endDate, image, offers, organizer, eventStatus). They make the item more complete for search engines and AI assistants.
How to fix. Add the recommended properties you can fill truthfully. Google's structured data documentation for Event describes each one.
A Recipe item lacks properties it must have (name, image). Without them the item is not eligible for Recipe rich results.
How to fix. Add the missing properties to the Recipe markup. Google's structured data documentation for Recipe lists them; test the page with the Rich Results Test.
A Recipe item lacks properties that are optional but recommended (author, recipeIngredient, recipeInstructions, totalTime, nutrition, aggregateRating). They make the item more complete for search engines and AI assistants.
How to fix. Add the recommended properties you can fill truthfully. Google's structured data documentation for Recipe describes each one.
A VideoObject item lacks properties it must have (name, thumbnailUrl, uploadDate). Without them the item is not eligible for VideoObject rich results.
How to fix. Add the missing properties to the VideoObject markup. Google's structured data documentation for VideoObject lists them; test the page with the Rich Results Test.
A VideoObject item lacks properties that are optional but recommended (description, duration, contentUrl or embedUrl). They make the item more complete for search engines and AI assistants.
How to fix. Add the recommended properties you can fill truthfully. Google's structured data documentation for VideoObject describes each one.
A JobPosting item lacks properties it must have (title, description, datePosted, hiringOrganization, jobLocation or applicantLocationRequirements). Without them the item is not eligible for JobPosting rich results.
How to fix. Add the missing properties to the JobPosting markup. Google's structured data documentation for JobPosting lists them; test the page with the Rich Results Test.
A JobPosting item lacks properties that are optional but recommended (validThrough, baseSalary, employmentType, identifier). They make the item more complete for search engines and AI assistants.
How to fix. Add the recommended properties you can fill truthfully. Google's structured data documentation for JobPosting describes each one.
A Review item lacks properties it must have (itemReviewed, author, reviewRating). Without them the item is not eligible for Review rich results.
How to fix. Add the missing properties to the Review markup. Google's structured data documentation for Review lists them; test the page with the Rich Results Test.
A Review item lacks properties that are optional but recommended (datePublished, reviewBody, name). They make the item more complete for search engines and AI assistants.
How to fix. Add the recommended properties you can fill truthfully. Google's structured data documentation for Review describes each one.
A HowTo item lacks properties it must have (name, step). Google no longer shows HowTo rich results, but other consumers still read valid markup.
How to fix. Add the missing properties to the HowTo markup. Google's structured data documentation for HowTo lists them; test the page with the Rich Results Test.
A HowTo item lacks properties that are optional but recommended (totalTime, supply, tool, image). They make the item more complete for search engines and AI assistants.
How to fix. Add the recommended properties you can fill truthfully. Google's structured data documentation for HowTo describes each one.
The document does not start with <!DOCTYPE html>, so browsers render it in quirks mode, with legacy layout rules that differ between browsers.
How to fix. Make <!DOCTYPE html> the very first line of every page.
The <head> contains an element that belongs in the body (a <div>, <img>, <a>…). Parsers end the <head> at that point, so every meta, canonical and hreflang tag after it is treated as body content and may be ignored.
How to fix. Move the element into <body>. Third-party snippets that inject markup into <head> are the usual cause.
A <body> tag appears in the source before the <head>. Everything in the head is then parsed as body content.
How to fix. Fix the template so the document is <html>, then <head>, then <body>.
The source contains more than one <html>, <head> or <body> start tag, usually from templates or includes nested inside each other.
How to fix. Make sure only the outer layout emits the document skeleton; partials should output fragments.
Something comes between <html> and <head>. Parsers then create an implied head, and the real one is mis-parsed.
How to fix. Put <head> immediately after the opening <html> tag.
The page has no <meta name="viewport">, so phones render it at desktop width, zoomed out. Search engines index the mobile version first.
How to fix. Add <meta name="viewport" content="width=device-width, initial-scale=1"> to <head>.
A substantial share of the page's text appears only after JavaScript runs. Google renders pages in a second pass that can lag the first by days; AI crawlers such as GPTBot and ClaudeBot do not run JavaScript at all and never see it.
How to fix. Render the main content on the server (SSR or static generation) so it is in the HTML response. Keep JavaScript for interaction, not for the copy itself.
Internal links that exist only after JavaScript runs. Crawlers that do not render cannot discover the pages behind them, and Google finds them only after rendering.
How to fix. Output navigation and in-content links as plain <a href> elements in the server HTML. Links injected by script, or built from onclick handlers, are the usual cause.
The <title> in the rendered page is different from the one in the HTML response, or exists only after rendering. Bots that do not render, and Google before it renders, index the original.
How to fix. Send the final title in the HTML response. In single-page apps, set it during server rendering rather than on the client.
The meta description in the rendered page is different from the one in the HTML response, or exists only after rendering.
How to fix. Send the final meta description in the HTML response rather than setting it from a script.
The first <h1> in the rendered page is different from the one in the HTML response, or exists only after rendering.
How to fix. Render the page's main heading on the server so every crawler reads the same one.
The rel=canonical in the rendered page points somewhere other than the one in the HTML response, or is added by script. Google says to keep the canonical in the HTML and not to change it with JavaScript; conflicting signals may see both ignored.
How to fix. Put the correct canonical in the server HTML and remove the script that rewrites or injects it.
The HTML response carries noindex and JavaScript removes it. Google does not render pages it is told not to index, so the page stays out of the index whatever the script does.
How to fix. If the page should be indexed, remove noindex from the server HTML. Never rely on JavaScript to lift a noindex.
The HTML response is indexable but the rendered page carries noindex. Crawlers that do not render will index it; Google drops it after rendering. Either way the signal is mixed.
How to fix. Decide whether the page should be indexed and say so in the server HTML. Remove the script that adds the robots meta tag.
The page navigates to another URL from a script after it loads. Crawlers that do not render never follow it, and Google treats it as a weaker signal than an HTTP redirect.
How to fix. Replace the script redirect with a server-side 301 (permanent) or 302 (temporary).
The page's URL or its links use hashbang (#!) URLs from Google's AJAX crawling scheme, which Google deprecated in 2015 and no longer supports. Everything after the # is ignored by crawlers.
How to fix. Move to real URLs with the History API (pushState) and render their content on the server; redirect the old #! URLs.
After JavaScript ran, the page had no visible text at all: the app failed to render, rendered only after a user action, or needs a browser feature the renderer does not have.
How to fix. Open the page with JavaScript errors visible (DevTools console) and fix what stops the content rendering. Check the console errors finding for the same URL.
The page logged errors to the console, or threw uncaught exceptions, while it rendered. Errors can stop content or links from rendering for search engines as well as visitors.
How to fix. Open the page in a browser with DevTools, read the console, and fix the errors from the first one down. Failed resource loads appear here too.
The HTML response has no internal links and almost no text, which is what a page built by JavaScript looks like before it runs. This crawl did not render pages, so what the page shows after JavaScript was not checked.
How to fix. Run the crawl again with rendering on (Thin pages is enough) to see the rendered content, links and the JavaScript findings.
Ensure every accesskey attribute value is unique. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "accesskeys") in the rendered page.
How to fix. Open the page, find the elements axe reports for "accesskeys", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/accesskeys
Ensure <area> elements of image maps have alternative text. WCAG success criteria: 2.4.4, 4.1.2. Checked by axe-core 4.11.4 (rule "area-alt") in the rendered page.
How to fix. Open the page, find the elements axe reports for "area-alt", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/area-alt
Ensure an element's role supports its ARIA attributes. WCAG success criteria: 4.1.2. Checked by axe-core 4.11.4 (rule "aria-allowed-attr") in the rendered page.
How to fix. Open the page, find the elements axe reports for "aria-allowed-attr", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/aria-allowed-attr
Ensure role attribute has an appropriate value for the element. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "aria-allowed-role") in the rendered page.
How to fix. Open the page, find the elements axe reports for "aria-allowed-role", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/aria-allowed-role
Ensure aria-braillelabel and aria-brailleroledescription have a non-braille equivalent. WCAG success criteria: 4.1.2. Checked by axe-core 4.11.4 (rule "aria-braille-equivalent") in the rendered page.
How to fix. Open the page, find the elements axe reports for "aria-braille-equivalent", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/aria-braille-equivalent
Ensure every ARIA button, link and menuitem has an accessible name. WCAG success criteria: 4.1.2. Checked by axe-core 4.11.4 (rule "aria-command-name") in the rendered page.
How to fix. Open the page, find the elements axe reports for "aria-command-name", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/aria-command-name
Ensure ARIA attributes are used as described in the specification of the element's role. WCAG success criteria: 4.1.2. Checked by axe-core 4.11.4 (rule "aria-conditional-attr") in the rendered page.
How to fix. Open the page, find the elements axe reports for "aria-conditional-attr", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/aria-conditional-attr
Ensure elements do not use deprecated roles. WCAG success criteria: 4.1.2. Checked by axe-core 4.11.4 (rule "aria-deprecated-role") in the rendered page.
How to fix. Open the page, find the elements axe reports for "aria-deprecated-role", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/aria-deprecated-role
Ensure every ARIA dialog and alertdialog node has an accessible name. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "aria-dialog-name") in the rendered page.
How to fix. Open the page, find the elements axe reports for "aria-dialog-name", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/aria-dialog-name
Ensure every ARIA input field has an accessible name. WCAG success criteria: 4.1.2. Checked by axe-core 4.11.4 (rule "aria-input-field-name") in the rendered page.
How to fix. Open the page, find the elements axe reports for "aria-input-field-name", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/aria-input-field-name
Ensure every ARIA meter node has an accessible name. WCAG success criteria: 1.1.1. Checked by axe-core 4.11.4 (rule "aria-meter-name") in the rendered page.
How to fix. Open the page, find the elements axe reports for "aria-meter-name", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/aria-meter-name
Ensure every ARIA progressbar node has an accessible name. WCAG success criteria: 1.1.1. Checked by axe-core 4.11.4 (rule "aria-progressbar-name") in the rendered page.
How to fix. Open the page, find the elements axe reports for "aria-progressbar-name", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/aria-progressbar-name
Ensure ARIA attributes are not prohibited for an element's role. WCAG success criteria: 4.1.2. Checked by axe-core 4.11.4 (rule "aria-prohibited-attr") in the rendered page.
How to fix. Open the page, find the elements axe reports for "aria-prohibited-attr", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/aria-prohibited-attr
Ensure elements with ARIA roles have all required ARIA attributes. WCAG success criteria: 4.1.2. Checked by axe-core 4.11.4 (rule "aria-required-attr") in the rendered page.
How to fix. Open the page, find the elements axe reports for "aria-required-attr", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/aria-required-attr
Ensure elements with an ARIA role that require child roles contain them. WCAG success criteria: 1.3.1. Checked by axe-core 4.11.4 (rule "aria-required-children") in the rendered page.
How to fix. Open the page, find the elements axe reports for "aria-required-children", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/aria-required-children
Ensure elements with an ARIA role that require parent roles are contained by them. WCAG success criteria: 1.3.1. Checked by axe-core 4.11.4 (rule "aria-required-parent") in the rendered page.
How to fix. Open the page, find the elements axe reports for "aria-required-parent", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/aria-required-parent
Ensure all elements with a role attribute use a valid value. WCAG success criteria: 4.1.2. Checked by axe-core 4.11.4 (rule "aria-roles") in the rendered page.
How to fix. Open the page, find the elements axe reports for "aria-roles", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/aria-roles
Ensure role="text" is used on elements with no focusable descendants. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "aria-text") in the rendered page.
How to fix. Open the page, find the elements axe reports for "aria-text", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/aria-text
Ensure every ARIA toggle field has an accessible name. WCAG success criteria: 4.1.2. Checked by axe-core 4.11.4 (rule "aria-toggle-field-name") in the rendered page.
How to fix. Open the page, find the elements axe reports for "aria-toggle-field-name", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/aria-toggle-field-name
Ensure every ARIA tooltip node has an accessible name. WCAG success criteria: 4.1.2. Checked by axe-core 4.11.4 (rule "aria-tooltip-name") in the rendered page.
How to fix. Open the page, find the elements axe reports for "aria-tooltip-name", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/aria-tooltip-name
Ensure every ARIA treeitem node has an accessible name. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "aria-treeitem-name") in the rendered page.
How to fix. Open the page, find the elements axe reports for "aria-treeitem-name", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/aria-treeitem-name
Ensure attributes that begin with aria- are valid ARIA attributes. WCAG success criteria: 4.1.2. Checked by axe-core 4.11.4 (rule "aria-valid-attr") in the rendered page.
How to fix. Open the page, find the elements axe reports for "aria-valid-attr", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/aria-valid-attr
Ensure all ARIA attributes have valid values. WCAG success criteria: 4.1.2. Checked by axe-core 4.11.4 (rule "aria-valid-attr-value") in the rendered page.
How to fix. Open the page, find the elements axe reports for "aria-valid-attr-value", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/aria-valid-attr-value
Ensure the autocomplete attribute is correct and suitable for the form field. WCAG success criteria: 1.3.5. Checked by axe-core 4.11.4 (rule "autocomplete-valid") in the rendered page.
How to fix. Open the page, find the elements axe reports for "autocomplete-valid", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/autocomplete-valid
Ensure that text spacing set through style attributes can be adjusted with custom stylesheets. WCAG success criteria: 1.4.12. Checked by axe-core 4.11.4 (rule "avoid-inline-spacing") in the rendered page.
How to fix. Open the page, find the elements axe reports for "avoid-inline-spacing", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/avoid-inline-spacing
Ensure <blink> elements are not used. WCAG success criteria: 2.2.2. Checked by axe-core 4.11.4 (rule "blink") in the rendered page.
How to fix. Open the page, find the elements axe reports for "blink", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/blink
Ensure buttons have discernible text. WCAG success criteria: 4.1.2. Checked by axe-core 4.11.4 (rule "button-name") in the rendered page.
How to fix. Open the page, find the elements axe reports for "button-name", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/button-name
Ensure each page has at least one mechanism for a user to bypass navigation and jump straight to the content. WCAG success criteria: 2.4.1. Checked by axe-core 4.11.4 (rule "bypass") in the rendered page.
How to fix. Open the page, find the elements axe reports for "bypass", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/bypass
Ensure the contrast between foreground and background colors meets WCAG 2 AA minimum contrast ratio thresholds. WCAG success criteria: 1.4.3. Checked by axe-core 4.11.4 (rule "color-contrast") in the rendered page.
How to fix. Open the page, find the elements axe reports for "color-contrast", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/color-contrast
Ensure <dl> elements are structured correctly. WCAG success criteria: 1.3.1. Checked by axe-core 4.11.4 (rule "definition-list") in the rendered page.
How to fix. Open the page, find the elements axe reports for "definition-list", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/definition-list
Ensure <dt> and <dd> elements are contained by a <dl>. WCAG success criteria: 1.3.1. Checked by axe-core 4.11.4 (rule "dlitem") in the rendered page.
How to fix. Open the page, find the elements axe reports for "dlitem", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/dlitem
Ensure each HTML document contains a non-empty <title> element. WCAG success criteria: 2.4.2. Checked by axe-core 4.11.4 (rule "document-title") in the rendered page.
How to fix. Open the page, find the elements axe reports for "document-title", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/document-title
Ensure every id attribute value used in ARIA and in labels is unique. WCAG success criteria: 4.1.2. Checked by axe-core 4.11.4 (rule "duplicate-id-aria") in the rendered page.
How to fix. Open the page, find the elements axe reports for "duplicate-id-aria", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/duplicate-id-aria
Ensure headings have discernible text. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "empty-heading") in the rendered page.
How to fix. Open the page, find the elements axe reports for "empty-heading", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/empty-heading
Ensure table headers have discernible text. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "empty-table-header") in the rendered page.
How to fix. Open the page, find the elements axe reports for "empty-table-header", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/empty-table-header
Ensure form field does not have multiple label elements. WCAG success criteria: 3.3.2. Checked by axe-core 4.11.4 (rule "form-field-multiple-labels") in the rendered page.
How to fix. Open the page, find the elements axe reports for "form-field-multiple-labels", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/form-field-multiple-labels
Ensure <frame> and <iframe> elements with focusable content do not have tabindex=-1. WCAG success criteria: 2.1.1. Checked by axe-core 4.11.4 (rule "frame-focusable-content") in the rendered page.
How to fix. Open the page, find the elements axe reports for "frame-focusable-content", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/frame-focusable-content
Ensure <iframe> and <frame> elements contain the axe-core script. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "frame-tested") in the rendered page.
How to fix. Open the page, find the elements axe reports for "frame-tested", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/frame-tested
Ensure <iframe> and <frame> elements have an accessible name. WCAG success criteria: 4.1.2. Checked by axe-core 4.11.4 (rule "frame-title") in the rendered page.
How to fix. Open the page, find the elements axe reports for "frame-title", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/frame-title
Ensure <iframe> and <frame> elements contain a unique title attribute. WCAG success criteria: 4.1.2. Checked by axe-core 4.11.4 (rule "frame-title-unique") in the rendered page.
How to fix. Open the page, find the elements axe reports for "frame-title-unique", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/frame-title-unique
Ensure the order of headings is semantically correct. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "heading-order") in the rendered page.
How to fix. Open the page, find the elements axe reports for "heading-order", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/heading-order
Ensure every HTML document has a lang attribute. WCAG success criteria: 3.1.1. Checked by axe-core 4.11.4 (rule "html-has-lang") in the rendered page.
How to fix. Open the page, find the elements axe reports for "html-has-lang", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/html-has-lang
Ensure the lang attribute of the <html> element has a valid value. WCAG success criteria: 3.1.1. Checked by axe-core 4.11.4 (rule "html-lang-valid") in the rendered page.
How to fix. Open the page, find the elements axe reports for "html-lang-valid", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/html-lang-valid
Ensure that HTML elements with both valid lang and xml:lang attributes agree on the base language of the page. WCAG success criteria: 3.1.1. Checked by axe-core 4.11.4 (rule "html-xml-lang-mismatch") in the rendered page.
How to fix. Open the page, find the elements axe reports for "html-xml-lang-mismatch", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/html-xml-lang-mismatch
Ensure <img> elements have alternative text or a role of none or presentation. WCAG success criteria: 1.1.1. Checked by axe-core 4.11.4 (rule "image-alt") in the rendered page.
How to fix. Open the page, find the elements axe reports for "image-alt", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/image-alt
Ensure image alternative is not repeated as text. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "image-redundant-alt") in the rendered page.
How to fix. Open the page, find the elements axe reports for "image-redundant-alt", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/image-redundant-alt
Ensure input buttons have discernible text. WCAG success criteria: 4.1.2. Checked by axe-core 4.11.4 (rule "input-button-name") in the rendered page.
How to fix. Open the page, find the elements axe reports for "input-button-name", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/input-button-name
Ensure <input type="image"> elements have alternative text. WCAG success criteria: 1.1.1, 4.1.2. Checked by axe-core 4.11.4 (rule "input-image-alt") in the rendered page.
How to fix. Open the page, find the elements axe reports for "input-image-alt", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/input-image-alt
Ensure every form element has a label. WCAG success criteria: 4.1.2. Checked by axe-core 4.11.4 (rule "label") in the rendered page.
How to fix. Open the page, find the elements axe reports for "label", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/label
Ensure that every form element has a visible label and is not solely labeled using hidden labels, or the title or aria-describedby attributes. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "label-title-only") in the rendered page.
How to fix. Open the page, find the elements axe reports for "label-title-only", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/label-title-only
Ensure the banner landmark is at top level. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "landmark-banner-is-top-level") in the rendered page.
How to fix. Open the page, find the elements axe reports for "landmark-banner-is-top-level", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/landmark-banner-is-top-level
Ensure the complementary landmark or aside is at top level. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "landmark-complementary-is-top-level") in the rendered page.
How to fix. Open the page, find the elements axe reports for "landmark-complementary-is-top-level", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/landmark-complementary-is-top-level
Ensure the contentinfo landmark is at top level. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "landmark-contentinfo-is-top-level") in the rendered page.
How to fix. Open the page, find the elements axe reports for "landmark-contentinfo-is-top-level", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/landmark-contentinfo-is-top-level
Ensure the main landmark is at top level. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "landmark-main-is-top-level") in the rendered page.
How to fix. Open the page, find the elements axe reports for "landmark-main-is-top-level", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/landmark-main-is-top-level
Ensure the document has at most one banner landmark. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "landmark-no-duplicate-banner") in the rendered page.
How to fix. Open the page, find the elements axe reports for "landmark-no-duplicate-banner", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/landmark-no-duplicate-banner
Ensure the document has at most one contentinfo landmark. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "landmark-no-duplicate-contentinfo") in the rendered page.
How to fix. Open the page, find the elements axe reports for "landmark-no-duplicate-contentinfo", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/landmark-no-duplicate-contentinfo
Ensure the document has at most one main landmark. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "landmark-no-duplicate-main") in the rendered page.
How to fix. Open the page, find the elements axe reports for "landmark-no-duplicate-main", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/landmark-no-duplicate-main
Ensure the document has a main landmark. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "landmark-one-main") in the rendered page.
How to fix. Open the page, find the elements axe reports for "landmark-one-main", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/landmark-one-main
Ensure landmarks are unique. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "landmark-unique") in the rendered page.
How to fix. Open the page, find the elements axe reports for "landmark-unique", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/landmark-unique
Ensure links are distinguished from surrounding text in a way that does not rely on color. WCAG success criteria: 1.4.1. Checked by axe-core 4.11.4 (rule "link-in-text-block") in the rendered page.
How to fix. Open the page, find the elements axe reports for "link-in-text-block", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/link-in-text-block
Ensure links have discernible text. WCAG success criteria: 2.4.4, 4.1.2. Checked by axe-core 4.11.4 (rule "link-name") in the rendered page.
How to fix. Open the page, find the elements axe reports for "link-name", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/link-name
Ensure that lists are structured correctly. WCAG success criteria: 1.3.1. Checked by axe-core 4.11.4 (rule "list") in the rendered page.
How to fix. Open the page, find the elements axe reports for "list", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/list
Ensure <li> elements are used semantically. WCAG success criteria: 1.3.1. Checked by axe-core 4.11.4 (rule "listitem") in the rendered page.
How to fix. Open the page, find the elements axe reports for "listitem", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/listitem
Ensure <marquee> elements are not used. WCAG success criteria: 2.2.2. Checked by axe-core 4.11.4 (rule "marquee") in the rendered page.
How to fix. Open the page, find the elements axe reports for "marquee", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/marquee
Ensure <meta http-equiv="refresh"> is not used for delayed refresh. WCAG success criteria: 2.2.1. Checked by axe-core 4.11.4 (rule "meta-refresh") in the rendered page.
How to fix. Open the page, find the elements axe reports for "meta-refresh", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/meta-refresh
Ensure <meta name="viewport"> does not disable text scaling and zooming. WCAG success criteria: 1.4.4. Checked by axe-core 4.11.4 (rule "meta-viewport") in the rendered page.
How to fix. Open the page, find the elements axe reports for "meta-viewport", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/meta-viewport
Ensure <meta name="viewport"> can scale a significant amount. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "meta-viewport-large") in the rendered page.
How to fix. Open the page, find the elements axe reports for "meta-viewport-large", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/meta-viewport-large
Ensure interactive controls are not nested as they are not always announced by screen readers or can cause focus problems for assistive technologies. WCAG success criteria: 4.1.2. Checked by axe-core 4.11.4 (rule "nested-interactive") in the rendered page.
How to fix. Open the page, find the elements axe reports for "nested-interactive", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/nested-interactive
Ensure <video> or <audio> elements do not autoplay audio for more than 3 seconds without a control mechanism to stop or mute the audio. WCAG success criteria: 1.4.2. Checked by axe-core 4.11.4 (rule "no-autoplay-audio") in the rendered page.
How to fix. Open the page, find the elements axe reports for "no-autoplay-audio", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/no-autoplay-audio
Ensure <object> elements have alternative text. WCAG success criteria: 1.1.1. Checked by axe-core 4.11.4 (rule "object-alt") in the rendered page.
How to fix. Open the page, find the elements axe reports for "object-alt", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/object-alt
Ensure that the page, or at least one of its frames contains a level-one heading. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "page-has-heading-one") in the rendered page.
How to fix. Open the page, find the elements axe reports for "page-has-heading-one", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/page-has-heading-one
Ensure elements marked as presentational do not have global ARIA or tabindex so that all screen readers ignore them. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "presentation-role-conflict") in the rendered page.
How to fix. Open the page, find the elements axe reports for "presentation-role-conflict", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/presentation-role-conflict
Ensure all page content is contained by landmarks. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "region") in the rendered page.
How to fix. Open the page, find the elements axe reports for "region", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/region
Ensure [role="img"] elements have alternative text. WCAG success criteria: 1.1.1. Checked by axe-core 4.11.4 (rule "role-img-alt") in the rendered page.
How to fix. Open the page, find the elements axe reports for "role-img-alt", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/role-img-alt
Ensure the scope attribute is used correctly on tables. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "scope-attr-valid") in the rendered page.
How to fix. Open the page, find the elements axe reports for "scope-attr-valid", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/scope-attr-valid
Ensure elements that have scrollable content are accessible by keyboard in Safari. WCAG success criteria: 2.1.1, 2.1.3. Checked by axe-core 4.11.4 (rule "scrollable-region-focusable") in the rendered page.
How to fix. Open the page, find the elements axe reports for "scrollable-region-focusable", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/scrollable-region-focusable
Ensure select element has an accessible name. WCAG success criteria: 4.1.2. Checked by axe-core 4.11.4 (rule "select-name") in the rendered page.
How to fix. Open the page, find the elements axe reports for "select-name", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/select-name
Ensure that server-side image maps are not used. WCAG success criteria: 2.1.1. Checked by axe-core 4.11.4 (rule "server-side-image-map") in the rendered page.
How to fix. Open the page, find the elements axe reports for "server-side-image-map", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/server-side-image-map
Ensure all skip links have a focusable target. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "skip-link") in the rendered page.
How to fix. Open the page, find the elements axe reports for "skip-link", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/skip-link
Ensure summary elements have discernible text. WCAG success criteria: 4.1.2. Checked by axe-core 4.11.4 (rule "summary-name") in the rendered page.
How to fix. Open the page, find the elements axe reports for "summary-name", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/summary-name
Ensure <svg> elements with an img, graphics-document or graphics-symbol role have accessible text. WCAG success criteria: 1.1.1. Checked by axe-core 4.11.4 (rule "svg-img-alt") in the rendered page.
How to fix. Open the page, find the elements axe reports for "svg-img-alt", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/svg-img-alt
Ensure tabindex attribute values are not greater than 0. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "tabindex") in the rendered page.
How to fix. Open the page, find the elements axe reports for "tabindex", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/tabindex
Ensure the <caption> element does not contain the same text as the summary attribute. An axe-core best practice, not a WCAG requirement. Checked by axe-core 4.11.4 (rule "table-duplicate-name") in the rendered page.
How to fix. Open the page, find the elements axe reports for "table-duplicate-name", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/table-duplicate-name
Ensure that each cell in a table that uses the headers attribute refers only to other <th> elements in that table. WCAG success criteria: 1.3.1. Checked by axe-core 4.11.4 (rule "td-headers-attr") in the rendered page.
How to fix. Open the page, find the elements axe reports for "td-headers-attr", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/td-headers-attr
Ensure that <th> elements and elements with role=columnheader/rowheader have data cells they describe. WCAG success criteria: 1.3.1. Checked by axe-core 4.11.4 (rule "th-has-data-cells") in the rendered page.
How to fix. Open the page, find the elements axe reports for "th-has-data-cells", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/th-has-data-cells
Ensure lang attributes have valid values. WCAG success criteria: 3.1.2. Checked by axe-core 4.11.4 (rule "valid-lang") in the rendered page.
How to fix. Open the page, find the elements axe reports for "valid-lang", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/valid-lang
Ensure <video> elements have captions. WCAG success criteria: 1.2.2. Checked by axe-core 4.11.4 (rule "video-caption") in the rendered page.
How to fix. Open the page, find the elements axe reports for "video-caption", and fix each one. Deque's guide to this rule, with examples: https://dequeuniversity.com/rules/axe/4.11/video-caption
On a phone-width screen the page is wider than the viewport, so visitors scroll sideways. Google indexes the mobile version of pages, and this is one of the problems its mobile-friendliness guidance names.
How to fix. Find the element that overflows (fixed widths, wide images or tables, long unbroken strings) and make it fit: max-width: 100%, flexible layouts, overflow-x: auto on tables.
The body text's computed size is under 12 px on a phone-width screen, which most visitors cannot read without zooming.
How to fix. Set the base font size to at least 16 px and size other text relative to it (rem). Check that the viewport meta tag is present, or the page is shown zoomed out.
Links or buttons smaller than 24 × 24 px sit within 24 px of another target, so a finger easily hits the wrong one (WCAG 2.2 success criterion 2.5.8, target size).
How to fix. Make small targets at least 24 × 24 px (48 px is the comfortable size), or add spacing between them.
The page's mobile PageSpeed run failed one of Lighthouse's mobile usability audits: a viewport meta tag that does not fit the page to the device width, or (on Lighthouse versions that still report them) legible font sizes and tap target spacing. The evidence names the failing audits.
How to fix. Add <meta name="viewport" content="width=device-width, initial-scale=1"> and keep it free of fixed widths and user-scalable=no. For font size and tap targets, use body text of at least 12 px and give links and buttons at least 24 × 24 px with space between them, then run PageSpeed again.
Words in the page's visible text that are not in the dictionary for its language (from <html lang>). Names and product terms show up here too until they are added to the accepted words.
How to fix. Correct the misspelled words. Add brand names, product names and other correct terms to your accepted words so they are not reported again.
More than five different words on the page are not in the dictionary. At that count it is usually an unproofread page, a page in a different language than its lang attribute says, or a run of names that should be accepted words.
How to fix. Proofread the page. If the words are correct, check that <html lang> matches the page's language and add the terms to your accepted words.
The page's language is not one the spell check covers (English, French and German), so its text was not checked.
How to fix. Nothing to fix on the page. Check its text with a spell checker for its language before publishing.
Stylesheets or scripts in the <head> hold up the first paint until they have downloaded and run. From the page's Lighthouse run.
How to fix. Inline the CSS the first screen needs and load the rest asynchronously; add defer or async to scripts that do not have to run before the page shows.
The page downloads CSS rules it never applies, which delays rendering and wastes bytes. From the page's Lighthouse run.
How to fix. Remove unused rules or split stylesheets per page or component, and load non-critical CSS later.
The page downloads JavaScript that never runs during the load, which costs bytes and main-thread time. From the page's Lighthouse run.
How to fix. Split bundles so each page loads only its own code, and defer code that is not needed until a user interacts.
Stylesheets are served with whitespace and comments a minifier would remove. From the page's Lighthouse run.
How to fix. Minify CSS in the build step (most bundlers do it in production mode).
Scripts are served with whitespace and comments a minifier would remove. From the page's Lighthouse run.
How to fix. Minify JavaScript in the build step and check that production builds are what the server sends.
Images without width and height attributes make the layout jump as they load, which counts against Cumulative Layout Shift. From the page's Lighthouse run.
How to fix. Give every <img> width and height attributes (or a CSS aspect-ratio) matching its intrinsic size.
Images below the fold are downloaded during the initial load, competing with what the visitor sees first. Lighthouse 13 no longer reports this audit; the rule fires only on runs that include it. From the page's Lighthouse run.
How to fix. Add loading="lazy" to images below the fold, and never to the main image at the top.
Images could be compressed further without visible loss of quality. On Lighthouse 13 this reads the image delivery insight, which also covers sizing and format. From the page's Lighthouse run.
How to fix. Re-encode images at a sensible quality (around 80 for JPEG and WebP) or serve them through an image CDN that does it for you.
Images are downloaded at a larger size than the page displays them, wasting bytes on phones in particular. From the page's Lighthouse run.
How to fix. Serve responsive images with srcset and sizes so each screen downloads the size it shows.
JPEG and PNG images that would be smaller as WebP or AVIF. From the page's Lighthouse run.
How to fix. Serve WebP or AVIF, with a <picture> fallback for older browsers, or let an image CDN negotiate the format.
HTML, CSS or JavaScript is served without gzip or Brotli compression. From the page's Lighthouse run.
How to fix. Turn on Brotli (or gzip) for text responses at the server or CDN.
Static files are served with a short or missing Cache-Control lifetime, so repeat visitors download them again. From the page's Lighthouse run.
How to fix. Serve fingerprinted static assets with Cache-Control: max-age=31536000, immutable.
The page is reached through redirects, each adding a round trip before anything loads. From the page's Lighthouse run.
How to fix. Link directly to the final URL and collapse redirect chains into a single hop.
The document took more than 600 ms to start arriving (time to first byte), which delays everything after it. From the page's Lighthouse run.
How to fix. Cache rendered pages at the server or CDN, speed up slow database or API calls, and check hosting capacity.
The page fetches critical resources from other origins without opening those connections early. From the page's Lighthouse run.
How to fix. Add <link rel="preconnect"> for the one or two third-party origins the first screen depends on.
The page has a very large number of elements, which slows style calculation, layout and every interaction. From the page's Lighthouse run.
How to fix. Paginate or virtualise long lists, remove hidden markup, and flatten deeply nested wrappers.
Parsing, compiling and running scripts takes a long time on a mid-range phone. From the page's Lighthouse run.
How to fix. Ship less JavaScript, defer non-critical scripts, and audit third-party tags.
The browser's main thread is busy for a long time during load, so the page responds late to input. From the page's Lighthouse run.
How to fix. Reduce JavaScript, break long tasks up, and move heavy work off the main thread.
The page downloads a large total number of bytes, which is slow and costly on mobile connections. From the page's Lighthouse run.
How to fix. Compress and resize images, drop unused code and fonts, and lazy-load what is below the fold.
The main content element took more than 2.5 seconds to render in the lab run. Google's "good" threshold is 2.5 s. From the page's Lighthouse run.
How to fix. Speed up the server response, preload the LCP image, and remove render-blocking resources in front of it.
Content moved around while the page loaded. Google's "good" threshold is 0.1. From the page's Lighthouse run.
How to fix. Reserve space for images, ads and embeds, and avoid inserting content above what is already on screen.
Real visitors (Chrome UX Report field data) waited more than 200 ms for the page to respond to their input. Only reported when PSI returns field data for the page. From the page's Lighthouse run.
How to fix. Break up long JavaScript tasks, defer work that runs on input, and keep event handlers small.
The first text or image took more than 1.8 seconds to appear in the lab run. Google's "good" threshold is 1.8 s. From the page's Lighthouse run.
How to fix. Cut server response time and remove render-blocking CSS and scripts.
Long main-thread tasks blocked input for more than 200 ms in total during load. From the page's Lighthouse run.
How to fix. Split long tasks, defer non-critical JavaScript, and remove unused third-party scripts.
The page's visible content filled in slowly in the lab run. Lighthouse's "good" threshold on mobile is 3.4 s. From the page's Lighthouse run.
How to fix. Improve the first render: server response, render-blocking resources and the size of what loads first.
The live robots.txt lets crawlers fetch this URL; the custom robots.txt you are testing would disallow it. Search engines would stop crawling it once the draft is published, and a page they cannot crawl can drop out of results.
How to fix. If the page should stay crawlable, change or remove the Disallow line shown in the evidence before publishing the draft. If blocking it is the intent, nothing to do.
The live robots.txt keeps crawlers out of this URL; the custom robots.txt you are testing would let them in. The crawl obeyed the live file, so the page itself was not fetched.
How to fix. If the URL should stay out of search, keep a matching Disallow line in the draft. If opening it up is the intent, publish the draft and crawl again to audit the page.
One or more of your custom extractors returned no value on this page, while another extractor did. The page looks like the ones you wrote the extractors for, but this field is missing: a product without a price, an article without an author or date, a page without its social tags.
How to fix. Open the page and check whether the value is really absent or only marked up differently. If it is absent, add it to the page. If it is there, widen the extractor's selector, XPath or pattern so it matches this template too.
One of your custom searches found its text or pattern in this page's source. The evidence lists each search that matched and how many times. Searches are yours to define, so a match means whatever you set them up to catch: a staging host, an old tracking tag, a placeholder left in a template.
How to fix. Review the matches on this page. If the search is looking for something that should not ship, remove it from the page or its template and crawl again. If a match is expected here, narrow the search or exclude the page.
The page can be indexed — it returns 200, is not noindex and is its own canonical — but Search Console recorded no impressions for it in the last 28 days. Google either has not indexed it or never shows it for any search.
How to fix. Inspect the URL in Search Console to see whether it is indexed. If it is not, link to it from relevant pages and add it to the sitemap. If it is indexed but never shown, the page may duplicate another or answer no query: improve its content, merge it, or noindex it.
Search Console shows impressions for this page in the last 28 days, yet the crawl found at most one internal link pointing to it. Pages that already earn visibility usually gain more when the rest of the site links to them.
How to fix. Add links to this page from related pages, navigation or hub pages, with descriptive anchor text. The evidence shows its impressions, clicks and current internal links.
The page carries noindex, but Search Console recorded clicks to it in the last 28 days. Either the noindex is recent and the page is about to drop out of search, or it was added by mistake to a page people find through Google.
How to fix. Check whether the noindex is intended. If not, remove it from the meta robots tag or the X-Robots-Tag header. If it is, expect the traffic to stop and make sure an indexable page serves those searches.
Search Console's URL Inspection says Google has not indexed this page, although it is indexable and the site links to it. The evidence shows Google's verdict and coverage state (for example "Crawled - currently not indexed" or "Discovered - currently not indexed").
How to fix. Improve what makes the page worth indexing (unique, substantial content), link to it from stronger pages, then request indexing in Search Console.
URL Inspection reports that Google's robots.txt check disallows this page, so Googlebot will not crawl it. This is what Google sees, which can differ from the robots.txt the crawler read.
How to fix. If the page should be in search, remove or narrow the Disallow rule that matches it, then re-test the URL in Search Console.
The canonical Google selected for this page is not the one the page declares (or the page itself when it declares none). Google is consolidating it into another URL; the evidence shows both.
How to fix. Make the signals agree: canonical tag, internal links, sitemap and redirects should all point at the URL you want indexed. If Google's choice is right, update your canonical.
Other websites link to this URL, but it returns an error (4xx or 5xx) or no response. Visitors from those links reach a dead end, and the value of the links is lost. The evidence shows the status and how many backlinks and referring domains point here.
How to fix. Restore the page, or 301-redirect the URL to the closest live page so the links count again. For valuable links, also ask the linking sites to update them.
Other websites link to this URL, which redirects. A single permanent redirect passes most of a link's value, but chains, temporary redirects and redirects to an unrelated page lose some of it.
How to fix. Make sure it is one 301 to the right page. For the most valuable referring domains, ask them to link to the final URL directly.
This page names an AMP version with <link rel="amphtml">, but that URL answered with an error, a redirect or nothing. Search engines drop an AMP version they cannot fetch.
How to fix. Fix the AMP URL so it returns 200, or remove the rel=amphtml link if the AMP version no longer exists.
The official AMP validator reports errors on this page. Invalid AMP is not served from the AMP cache and loses AMP-only search features. The evidence shows the error count and the first three messages.
How to fix. Fix each validator error (the AMP validator browser extension shows them in place), then re-crawl.
An AMP page must carry <link rel="canonical"> pointing at its regular version, or at itself when it has none. Without it the AMP page is invalid.
How to fix. Add a canonical link to the regular (non-AMP) URL of this content.
This page links to an AMP version, but that AMP page's canonical names a different URL. The pair should point at each other: amphtml one way, canonical the other.
How to fix. Set the AMP page's canonical to this page's URL, or link this page to the AMP version that belongs to it.
This page's rel=amphtml link points at a URL that is not an AMP document (no <html amp> or <html ⚡>). Search engines ignore the link.
How to fix. Point rel=amphtml at the real AMP version, or remove the link.
This AMP page is not listed in the XML sitemap. AMP pages are found through their regular page's rel=amphtml link, so this is optional; listing them helps when you want them recrawled faster.
How to fix. If the AMP pages matter to you, add them to the sitemap, or a separate AMP sitemap.
The crawl's "suggest title and description" prompt proposed a title that differs from the page's current one. It is a suggestion, not a defect: compare the two and keep whichever describes the page better for searchers.
How to fix. Read the suggestion on the Extraction tab next to the current title, and adopt it, adapt it or ignore it.
The crawl's grammar prompt listed mistakes in this page's visible text. The evidence shows how many and the first one; the full list is on the Extraction tab. AI can be wrong, so check each one.
How to fix. Correct the confirmed mistakes in the page copy, then re-crawl.