Work through issues

A site's Issues tab has a switch with three lists. Only the first is about something wrong.

• Issues: what can get in the way of Google crawling or indexing your pages.
• Suggestions: best practices, and limits that are a matter of opinion.
• Watched: what is true of the site right now, such as which pages ask to stay out of Google. We watch it so a change shows up.

Suggestions and watched items never alert, and don't change the sentence at the top of the site's overview. The rest of this guide is about issues.

• Critical: this can keep pages out of Google. Fix it first.
• Error: this can stop Google from crawling or indexing the pages as you mean it to.
• Warning: a smaller problem, worth fixing when you can.

A severity is about crawling and indexing, not a prediction about rankings. An alert goes out for a new critical issue, or one that came back, a new error on a key page, and a new error on many pages of one kind at once, after we fetch those pages a second time. Everything else waits for the weekly digest. Choose who gets alerts says where they go.

Each row is one issue: one problem on one kind of page, such as every page under /blog/. The line above the list counts them, as in "12 issues on 340 pages", and a page with three issues counts once.

• Status shows Open, Fixed, Hidden or Marked as known.
• Severity and Category narrow the list.
• New marks pages where we found the problem for the first time, and Came back pages where it returned after a fix.
• Export CSV downloads the list as filtered, one line per page.

On the site's Overview, "Fix first" picks the issues to start with, and "Why first?" says how each was ranked: by severity, how sure we are, how many pages it is on, and how much they matter. Your homepage and key pages count most.

The top line says where it stands, such as "Open since Oct 21" or "Fixed, verified Oct 23".

• How to fix says what to change, and "Fixed when:" what must be true afterwards.
• Copy instructions for your developer or AI assistant copies the problem, the pages and what we saw, ready for a ticket.
• Where lists the pages, and "Pages like" narrows them to one kind.
• What we saw shows the page you picked: when we fetched it and what it said. Its Technical details include the cache headers, since a cache can answer with a copy older than your last deploy.

1. Deploy the change.
2. Open the issue and click "I've fixed this". To claim only some pages, tick them under Where first.
3. If you like, add a link to the change, such as a pull request, and a note. We never open the link.
4. Click "Record it and check now".

We fetch those pages again at once, and nothing is called fixed until the problem is gone. Some problems compare pages with each other, so only the next full crawl can tell: "How to verify" on the issue says so. Rechecks need a verified site.

Under "Fixes recorded", each fix ends as one of these:

• Verified: gone when we looked again.
• Partly verified: gone from some pages, not from others.
• Still there: the problem is unchanged.

If a page could not be read, or a cache answered with an old copy, we look again after 10 minutes and after an hour. "Check again" asks at once. A fix still waiting, or still there, is checked again by the next deploy check and the next full crawl.

With the step in Check every deploy, each deploy rechecks every fix waiting for an answer, and closes issues that are gone from the pages it checked, without anyone clicking "I've fixed this".

With Search Console connected, some issues are marked "From Google". They are what Google itself reported about a page, not what our fetch saw, so fetching the page again can't close them.

1. Make the change "How to fix" describes, if it asks for one, and deploy it.
2. On the issue, click "Open in Search Console".
3. In Search Console, click "Request indexing" to ask Google to crawl the page again.

Google decides when it crawls. The issue closes on its own once Google reports the change: we read Google's answer on every full crawl.

Click "Hide…" on the issue, or tick pages under Where and click "Hide…" there. Choose which pages: the ones you ticked, URLs matching a pattern such as /blog/*, or everywhere on this site. Then choose why:

• Ignore for now: hidden until a date, 90 days ahead unless you pick another.
• Won't fix: hidden for good.
• False positive: the rule is wrong here. We count these to improve the rule.

A reason is required, so the rest of the team knows. A hidden issue is still checked on every crawl, but leaves the list and the counts and never alerts. Set Status to Hidden to see them. To bring one back, open the site's Settings, then Advanced, and click "Show again" under Hidden issues.

If a site starts with more than you can fix now, click "Mark today's issues as known" above the list. Today's issues leave the list and the counts, never alert, and from then on the overview shows only what is new or came back. One that is fixed and later returns comes back to the list. Set Status to Marked as known to see them, and "Undo", in the line above the list, puts them all back.