The checks we refuse to run.
Most SEO tools compete on rule count. That rewards adding checks, including the ones the documentation contradicts, because nobody audits an audit tool. This is the opposite list: 14 rules we could easily ship, that would make our number bigger, and that we decline to implement because the primary source says they are wrong. Pull requests adding them get closed with a link here.
The verdicts are not all the same shape. 11 claims are contradicted by the document that governs them, 2 are misreadings (a real documented number attached to the wrong object, the most durable kind because the number itself is findable), and 1was simply true until the source moved. Most of the governing documents are Google's; two are not, so read the citation on each entry rather than assuming.
The claims
- #1False
“Meta descriptions must stay under 155 to 160 characters”
Google's snippet documentation says it outright: there is no limit on how long a meta description can be. Truncation is a display behaviour that varies with device width, not an indexing event. The documented failures are a MISSING description (Google then writes the snippet itself) and one templated description repeated across a whole cluster.
Google Search Central: control your snippetsWe check instead:content/meta-description-presence,content/meta-uniqueness - #2False
“Title tags over 60 characters get penalised or rewritten”
Google's title-link page opens with the opposite of the folklore: while there is no limit on how long a title element can be, the title link is truncated in Search results as needed, typically to fit the device width. That is display-side cropping measured in pixels, not an indexing or ranking event, and no character count appears anywhere on the page. What the same page DOES document is why Google replaces a title link, and none of it is length: part of the title text missing (its own example is the literal "| Site Name"), boilerplate repeated across a subset of pages, a stale year on a page reused annually, a title that does not describe the page. pseolint checks the first two, which are mechanical; the last two need editorial judgement a crawler does not have, so we leave them to you rather than guess.
Google Search Central: influencing your title linksWe check instead:content/title-uniqueness - #3Unsupported
“og:description should be 70 characters”
No such number exists in any specification. Meta's sharing guide says a description is usually between 2 and 4 sentences; ogp.me asks for one to two sentences. Open Graph tags are not a ranking input at all, they shape the social and AI-summary card. What IS in the spec and widely missed: og:type and og:url are required properties.
ogp.me: the Open Graph protocolMeta: a guide to sharing for webmastersWe check instead:tech/og-completeness - #4Misread
“Search engines can only process 2 MB of total website size”
A real number attached to the wrong object. Googlebot's documented limit is 2 MB per fetched FILE, uncompressed: every HTML page, stylesheet and script gets its own budget, and PDFs get 64 MB. There is no total-site or total-page-weight crawl ceiling. A 21 MB page whose HTML is 112 kB has a Core Web Vitals problem, not a crawl-truncation one.
Google Search Central: GooglebotWe check instead:tech/html-size,tech/resource-weight,tech/core-web-vitals - #5Outdated
“Googlebot indexes the first 15 MB of your HTML”
This one was true. The 15 MB figure lived in Google's documentation for years and most SEO tools still cite it. The February 2026 revision of the Googlebot page cut the documented per-file crawl limit to 2 MB. Folklore and fact swap places when the source document moves, which is why every rule here links to the living doc rather than a summary of it.
Google Search Central: GooglebotWe check instead:tech/html-size - #6False
“A missing meta keywords tag hurts your ranking”
Google's supported-tags page lists keywords as a tag it does not use, with no effect on indexing or ranking at all, and it has said so publicly since 2009. Any audit that still flags a missing keywords tag is dating itself.
- #7Misread
“A wrong or missing html lang attribute is an SEO problem”
Google is explicit that it does not use code-level language information such as lang attributes, and detects language from visible content instead. The consequence cuts the other way: when your declared language and your actual content diverge, Google indexes by what it DETECTED, so the declared targeting silently fails. The attribute still matters for accessibility.
Google Search Central: managing multi-regional sitesWe check instead:tech/language-mismatch - #8False
“Sitemaps need priority and changefreq values”
Google documents that it ignores both. It does use lastmod, but only when the value is consistently and verifiably accurate. A sitemap that stamps every URL with the same generated timestamp teaches Google to distrust the one sitemap field that actually works.
Google Search Central: build and submit a sitemapWe check instead:tech/sitemap-hygiene - #9Obsolete
“Paginated archives need rel=next and rel=prev”
Google's pagination guidance is one sentence long and carries no date: in the past Google used rel=next and rel=prev to identify next-page and previous-page relationships, Google no longer uses these tags, although these links may still be used by other search engines. The 2019 announcement that made the rounds said support had already been dropped years earlier, so nobody outside Google knows when it actually stopped. Harmless to keep for whichever other engines read it; pointless to add for Google.
- #10False
“Pages need 300 or more words to rank”
Google's helpful-content guidance answers this in its own words: are you writing to a particular word count because you heard Google has a preferred one? No, they do not. Word-count floors exist in SPAM detection at template scale, where a thousand 40-word pages differing by one city name is a doorway pattern, but that is a policy-risk signal rather than a per-page ranking factor.
Google Search Central: creating helpful contentWe check instead:spam/thin-content,content/unique-value - #11Unsupported
“Multiple meta description tags trigger a penalty”
Neither Google's documentation nor Lighthouse checks for it. Duplicated tags carrying different content are undefined behaviour worth tidying, but the place duplicates genuinely hurt is robots directives: Google applies the MOST RESTRICTIVE rule it finds across meta robots, meta googlebot and the X-Robots-Tag header, so one forgotten noindex in a conflicting pair silently wins.
Google Search Central: robots meta tag specificationsWe check instead:tech/meta-robots-conflict - #12Unsupported
“An hreflang set is invalid without x-default”
Google's wording is consider adding a fallback page and use the x-default value: a recommendation, not a requirement. What the same page does document as a hard constraint is the code itself: only ISO 639-1 languages and ISO 3166-1 Alpha 2 regions are supported, and it names es-419 outright as a code that is not. Read the failure precisely, because the popular summary overstates it: for a code reserved for something else, Google ignores THAT PART of the annotation, naming EU, UN and UK as examples. So en-UK is not discarded, it degrades to a bare en that now collides with whatever real en alternate the set already declares. Either way nothing is surfaced in Search Console.
Google Search Central: localized versions of your pagesWe check instead:tech/hreflang-validity,tech/hreflang-consistency - #13Obsolete
“FAQPage JSON-LD earns you an FAQ rich result”
It did, for anyone, until September 2023, when Google narrowed the FAQ rich result to well-known authoritative government and health sites. It then stopped appearing at all: the changelog entry dated May 8, 2026 announced the feature would no longer appear in Google Search starting May 7, 2026, and on June 15, 2026 Google deleted the FAQPage documentation outright. There is no successor. QAPage still has a live rich result, but its own documentation restricts it to pages where users can submit answers, which a site-authored FAQ is not. Writing real question-and-answer content still pays, as extractable prose that an answer engine can lift whole; the markup no longer buys anything in Google Search.
Google Search Central: removing the FAQ rich resultGoogle Search Central: Q&A (QAPage) structured dataWe check instead:aeo/faq-coverage,aeo/answer-first - #14Unsupported
“CSS complexity hurts your ranking”
Rule counts, duplicated selectors, !important usage and vendor prefixes have no documented ranking role. They matter through exactly two documented mechanisms: a single file blowing past the per-file fetch limit, or rendering slow enough to degrade Core Web Vitals. Fix those two and selector count is a code-review topic rather than an SEO one.
Google Search Central: understanding page experienceWe check instead:tech/html-size,tech/core-web-vitals
How this list is maintained
Entry #5 is the important one. “Googlebot reads the first 15 MB” was the correct, documented answer for years, and the skeptics repeating “2 MB” were garbling it. Then the February 2026 revision of the Googlebot page cut the per-file figure to 2 MB and the garbled number became closer to the truth than the well-sourced one. Documentation moves, so a rule that hard-codes a number without citing its living source will eventually be confidently wrong.
The FAQPage entry is the one this page had to eat. Until August 2026 this very page shipped FAQPage JSON-LD, synthesising question text (“Is it true that …?”) that appeared nowhere in the visible DOM, which Google's structured-data policy forbids in as many words: don't mark up content that is not visible to readers. It was also markup for a rich result that had already been removed from Search on May 7, 2026. Both blocks are gone; what replaces them is an Article node whose dates and author match the visible byline above. The engine's own aeo/faq-coverage rule stopped recommending the markup in the same change.
That is why every pseolint finding links to the primary source that documents the behaviour, and why this page carries a date. If you can show a current primary source that contradicts an entry here, that is a bug report we want: open an issue. The companion list of things we genuinely cannot detect yet lives in the calibration methodology, and the long-form version of this research is at SEO folklore vs. what Google actually documents.
Every rule we do run cites the doc that backs it.
Run a free audit