EEAT Signal Scanner: The EEAT Checker Chrome Extension I Built

I stared at a page I had just written. It read well. It looked clean. But would Google trust it?

I could not tell. And most tools I tried could not tell me either.

So I built my own. It is called EEAT Signal Scanner. It is an SEO Chrome extension that works as an EEAT checker right inside your browser. One click scans the page you are on. It scores Experience, Expertise, Authoritativeness, and Trust. Then it lists what to fix.

This post is the full story of how I built it. What it reads. How every score is calculated, with the real numbers. What it gets wrong. And what it cannot do at all.

Nothing is hidden here. If the scanner has a weak spot, I will say so.

Quick facts

Here is the scanner in one table. Every line comes from the code and the manifest file, not from marketing copy.

Detail	What it is
Name	E-E-A-T Signal Scanner
Version	0.4.1
Type	Chrome extension built on Manifest V3
Price	Free
Where analysis runs	Locally, inside the browser tab you are on
Data sent to a server	None. The code makes no network requests
Scores it gives	Overall E-E-A-T, four pillar scores, and a separate technical score
Extra flags	Niche badge (health, finance, legal, travel safety) and AI-content risk
Languages	English keyword lists only
Where to get it	Not on the Chrome Web Store yet. You load it as an unpacked extension
How I built it	I designed and tested it. Claude, an AI model, wrote the code with me

You can grab the files from the E-E-A-T Signal Scanner page. The installation steps are further down. It is a handy tool for all the SEO Specialists out there.

Why I built it

I wanted to know if a page showed the signs of a trustworthy source. Not a vague feeling. Visible evidence I could point at and fix.

Google describes E-E-A-T as Experience, Expertise, Authoritativeness, and Trust. It also says that E-E-A-T itself is not a specific ranking factor. Its systems look for a mix of signals that line up with it. So a scanner cannot predict rankings. But it can show whether the evidence is on the page.

What bothered me about existing checkers

I looked at what already exists before I wrote any code. EEAT checkers are real, and several are good. Tools such as EEAT Analyser and the Content Raptor E-E-A-T checker are proof of that. So I never planned to claim mine was the first.

But four things kept nagging me.

• One formula for everything. A medication page and a hobby blog got the same weights.
• Noise in the reading. Menus, footers, and widgets sat inside the text being scored.
• Scores without fixes. A number is not a to-do list.
• Unclear limits. Few tools say plainly what they cannot see.

The five rules I set

1. Read the article, not the whole page.
2. Change the scoring by topic. Stricter for health, money, law, and safety.
3. Hand over the fix, not just the gap.
4. Stay on your machine. No servers, no accounts.
5. Be open about the limits. Including in this post.

How it grew

I did not get it right the first time. I tested each version on real pages and fixed what broke. Claude, an AI model, wrote the code with me, and I made the decisions and ran the tests.

Version	What changed
0.1	Core scanner: four pillar scores, YMYL flag, AI-content risk, plain fix list
0.2	Reads only the cleaned article content. Added domain tiers, citation diversity, editorial review, real contact channels, freshness decay
0.3	Word-boundary keyword matching. Added author sameAs checks and a separate technical score
0.4	Schema snippet generator, per-page score history, toolbar badge, report export, a logo
0.4.1	Accuracy fixes: a byline check that fired on ordinary phrases, a first-person count that missed capitalised words, prices and percentages that were never counted, author verification that accepted any company profile link, a date check that could pick up a comment date, domain checks that matched part of a hostname, words that fused together on minified HTML, and an unused permission

What you see after a scan

Click the icon, press Scan This Page, and the popup fills in within a second or two. Here is every element, top to bottom.

Element	What it tells you
Overall E-E-A-T score	One number from 0 to 100. It blends the four pillars, then subtracts an AI-content penalty
History line	Your last score for this exact URL, how long ago, and the change
Niche badge	Shows when the page looks like health, finance, legal, or travel-safety content, and says stricter scoring was applied
AI-content risk badge	Appears only at medium or high risk
Four pillar bars	Experience, Expertise, Authoritativeness, and Trust, each scored 0 to 100
Technical bar	A separate score for basic on-page SEO. It is not part of the E-E-A-T number
Suggested Fixes	Plain-language actions, one per gap the scan found
Ready-to-Paste Schema Fixes	JSON-LD for Person and Article markup, shown only when that markup is missing
Context and Insights	Short facts such as link diversity, commercial-link share, and content age
Copy Report and Download .md	Exports the whole result as a Markdown report

The toolbar icon also shows the overall score as a badge. It turns green at 75 and above, amber from 50 to 74, and red below 50. Those cutoffs are mine. Google does not publish any.

The insights panel in detail

The panel at the bottom is where the small but useful facts live. It reports:

• the detected topic area, and whether stricter scoring is on
• whether a second named reviewer was found, such as an editor or fact-checker
• whether the author is linked to an outside profile through sameAs
• the share of external links that point to distinct domains
• the share of links in the content that are booking or sales calls to action
• how many days ago the content was published or updated
• word count and the number of subheadings
• review count and average rating, when review markup exists

How it works, step by step

The scanner has two parts. A content script reads the page. A popup shows the result. They talk through a single message.

Here is the full path, from click to score.

1. You click Scan This Page. The popup checks that the tab is a normal web page. Browser pages such as the extensions screen are refused.
2. The popup sends one message. It asks the content script in that tab to run a scan.
3. The script finds the article. It looks for the first of these with more than 200 characters of text: article, main, [role=main], .post-content, .entry-content, .article-content. If none qualifies, it falls back to the whole body.
4. It works on a cleaned copy. The script clones that section so your page is never touched. It removes scripts, styles, forms, navigation, and any element whose class contains “cookie”, “popup”, “modal”, “comment”, “share”, “related”, or “sidebar”. In fallback mode, it also removes the header, footer, and aside.
5. It extracts the evidence. Text is capped at the first 200,000 characters. Links, images, dates, and JSON-LD blocks are read from the copy or the document.
6. Seven detectors run. Niche, Experience, Expertise, Authoritativeness, Trust, AI-content risk, and technical signals each return a score and the facts behind it.
7. The scores are combined. Pillar scores are weighted, then an AI-content penalty is subtracted.
8. Fixes and insights are built. Every gap becomes a plain sentence. Missing schema becomes a ready-to-paste snippet.
9. The popup renders and saves. It draws the bars, records the score for this URL, and sets the toolbar badge.

Which part of the page each detector reads

Not every check should read the cleaned article. Policy links and contact details usually sit in a header or footer, which the cleaning step removes. So the scanner splits the work.

Detector	Reads
Niche, Experience, Expertise, Authoritativeness, AI-content risk	The cleaned article copy. Expertise also reads the author meta tag and the JSON-LD from the whole document
Trust	The whole document, so footer links and meta tags count
Technical	The whole document, but word count comes from the cleaned article

Two details that decide accuracy

• Whole-word matching. Keyword checks use word boundaries. A search for “visa” no longer matches inside “advisable”.
• Domain labels, not suffixes. A government link is found by reading the domain’s labels, so .gov.np, .gov.uk, and .gov.au all count.

A timing note

The content script starts when the page is idle. If a bio or date loads later, the first scan can miss it. Wait for the page to finish loading, then scan again.

The four pillars and their points

Each pillar starts at zero. Evidence adds points. The score is capped at 100. Here is exactly what earns points, in the order the code checks it.

Experience: has someone really done this?

Signal	How the scanner checks it	Points
First-person voice	Counts I, we, my, our, and their contractions. More than 5 earns points; more than 15 earns more	20, then 10 more
Narrative phrases	Finds phrases such as “I tested”, “we tried”, “in my experience”, “after using”, “hands-on”	25
Specific detail	Counts numbers with a unit (12 km, 3 days), prices ($1,090) and percentages. Five or more, then fifteen or more	15, then 5 more
Original images	Share of images not served from ten known stock-photo sites	Up to 25

The stock list covers Shutterstock, iStock, Getty Images, Unsplash, Pexels, Pixabay, Depositphotos, 123RF, Dreamstime and Freepik. An image from any other host counts as likely original. That is a guess, and the post says so in the limits section.

Expertise: does the author know the subject?

Signal	How the scanner checks it	Points
Visible byline	An author element, the author meta tag, or “written by” and “by Name” text near the top	16
Author link	A link whose address contains “author” or “/guide/”, or rel=author	8
Author bio text	An author box, about-author or author-bio element with over 80 characters, or similar text around the author link	10
Person schema	A Person type in JSON-LD	14
Verified identity	A Person node whose sameAs links to LinkedIn, X, ORCID, Facebook, Instagram, Muck Rack or Google Scholar	16
Organization schema	An Organization type in JSON-LD	6
Credentials	Patterns such as MD, PhD, JD, CPA, RN, certified, licensed, board certified, years of experience, guide at, instructor	14
Editorial review	“Edited by”, “reviewed by”, “fact-checked by” or “checked by” plus a name near the top	16

The editorial review check is one I wanted on purpose. A second named person is a stronger accountability signal than an author alone.

Authoritativeness: do reliable sources back this up?

Signal	How the scanner checks it	Points
Outbound links	At least one link to another domain inside the article	10
Source variety	Three or more distinct external domains	10
Government or university	A domain with a gov or edu label, so .gov.np, .gov.uk and .edu.au count. A .ac.uk domain does not	35
Recognized institution	A link to one of 16 listed bodies, such as WHO, the UN, UNESCO, the World Bank, Mayo Clinic or Nature	20
Wikipedia only	Only if there is no government, university or institution link	8
Citation language	“According to”, “source:”, “study found”, “research shows”, “cited by”, “reference:”	15

This pillar can reach 90, not 100. I chose that because the page alone can never prove authority. The rest lives off the page.

Trust: can a reader rely on this page?

Signal	How the scanner checks it	Points
HTTPS	The page address starts with https	13
Privacy, contact, about, terms links	A link whose address contains each word	10, 10, 7 and 5
Review markup	Review or AggregateRating in JSON-LD	12
Real contact channel	A tel: link or a WhatsApp link	13
Freshness	Age of the page date: 120 days or less, 365, 730, or older	25, 15, 8 or 3

Trust tops out at 95. A page with no readable date gets no freshness points at all.

One detail on dates. The scanner reads the article modified time first, then the published time, then the first time tag on the page. Using the page-level tags first avoids picking up a comment date by mistake. But a bare time tag is only a fallback. On a page with no article meta tags, it can still be a comment date.

Why the pillars are capped

A score of 100 would suggest nothing is left to improve. That is never true for a real page, and it is not what the scanner is trying to say.

Niche-aware scoring

Not every page carries the same risk. A wrong tip about a trekking permit can leave a hiker stranded. A wrong tip about a pancake just makes a flat pancake.

Google treats this difference seriously. Its quality rater guidelines single out YMYL topics, short for “Your Money or Your Life”. I built that idea into the scanner.

Before scoring, the scanner reads the article text and looks for topic keywords in four verticals.

Vertical	Keywords the scanner looks for
Health	diagnosis, treatment, symptom, medication, dosage, therapy, disease, surgery, prescription, clinical trial, mental health
Finance	mortgage, loan, interest rate, investment, retirement, tax, insurance, credit score, bankruptcy, cryptocurrency, stock market
Legal	lawsuit, attorney, legal advice, divorce, custody, liability, contract law
Travel safety	permit, mandatory, licensed guide, restricted area, checkpoint, penalty, visa, altitude sickness, rescue, evacuation, banned, prohibited

Travel safety is my own addition. I work with trekking content, and that niche has real safety stakes that the standard YMYL list does not name.

The two-match rule

One keyword is not enough. A recipe blog can say “tax” once in a sidebar note. That should not flip it into a finance page.

So the rule is simple. The vertical with the most matches wins, and it needs at least two different keywords to count as YMYL. If no vertical reaches two, the page stays “general”. If two verticals tie, the one listed first in the table above wins.

Matching uses word boundaries. “Visa” will not fire inside “advisable”. An early version used plain substring matching and made exactly that mistake.

What changes when a page is YMYL

The four pillar scores stay the same. What changes is how much each one counts toward the overall score.

Pillar	General page weight	YMYL page weight
Experience	0.30	0.15
Expertise	0.25	0.35
Authoritativeness	0.20	0.25
Trust	0.25	0.25

Experience drops from 0.30 to 0.15 on sensitive topics. Expertise rises from 0.25 to 0.35. On a medical or safety page, who wrote it matters more than how vividly they told the story.

The popup shows a badge when this mode is on, for example, “Travel Safety content, stricter scoring applied”. Extra suggestions also appear. On YMYL pages, the scanner asks for stated credentials and for a named reviewer.

One limit you should know

The keywords are English and exact. I tested a short page with “permits and visas” and “checkpoints issue penalties”. It stayed “general” because the plural forms do not match. The same page with “permit”, “visa”, “checkpoint”, and “penalty” was flagged as travel safety.

That is a real gap. The fix is stemming, or a longer keyword list, and it sits on my roadmap.

AI-content risk

Google does not ban AI-written content. It does act against content made at scale to manipulate rankings, and it has said so in its spam policies. Most useful pages are written with care and carry a human voice. Raw, unedited machine text often does not.

I added a risk meter that looks for three patterns. It does not claim to know who wrote the page. It only reports how much the text resembles unedited AI output.

Measure	What it looks at	Points added to the risk score
Filler phrases	14 stock phrases such as “in today’s digital age”, “delve into”, “it is important to note”, “furthermore”, “moreover”, “plays a crucial role”	Filler hits divided by sentence count, times 300, capped at 40
Sentence rhythm	Standard deviation of sentence length, in characters. Needs more than 20 sentences.	Under 15 adds 40. Under 25 adds 20.
Vocabulary variety	Type-token ratio: unique words divided by total words, over the first 3,000 words	Under 0.35 adds 30. Under 0.45 adds 15.

The three parts are added together and capped at 100. A total of 55 or more is “high”. A total of 25 or more is “medium”. Anything lower is “low”.

What the score does to your result

The risk score takes points off the overall E-E-A-T score. The deduction is the risk score divided by 100, times 20, rounded. So the worst case is a 20-point penalty. It never wipes out a score.

The popup also shows an amber or red badge, and a suggestion asks you to add specific examples and a distinct voice.

Where it misleads you

I measured this on real text, and the result matters.

Vocabulary variety falls as a text gets longer, because common words repeat. I ran roughly 3,200 words of ordinary technical prose through the scanner. It scored a type-token ratio of 0.22. That alone adds 30 points, which is enough for a “medium” label.

So a long, perfectly human article can show “medium” with no filler phrases at all. Treat “medium” on a long page as a weak signal. Treat “high” as a reason to reread the text.

Filler phrases are a blunt tool too. Human writers say “furthermore” as well. And a model told to avoid those phrases will skip them. This meter is a nudge to edit, nothing more.

Technical and content readiness

E-E-A-T is about trust and credibility. Meta tags and canonical links are about plumbing. They are both useful, but they are different jobs.

So the scanner shows a second bar called “Technical and Content Readiness”. It does not feed into the overall E-E-A-T number. I kept it apart so a well-tagged but empty page cannot look trustworthy.

Check	Points
Meta description present	15
Meta description length 70 to 160 characters	10
Canonical tag	15
Open Graph title, description and image all present	15
Article, NewsArticle or BlogPosting schema	15
600 or more words (300 or more earns 8)	15
Three or more H2 or H3 headings	15

The total is 100. Headings are counted inside the article or main area first. If the page has neither, it counts all H2 and H3 tags.

Word count uses the cleaned article text, not the menu and footer. That matters. A page with 1,500 words of navigation and 120 words of content should not pass as long-form.

The thin-content suggestion fires under 300 words. Word count is not a ranking factor on its own, so I describe it as a limit on potential, not as a penalty.

Fixes and the schema generator

A score alone does not help anyone. So every gap the scanner finds becomes a plain instruction.

The suggestions are rule-based. Each one fires when a specific check fails. Here are the main ones.

If the scanner finds	It suggests
No byline	Add a visible author name and link it to a bio page
Byline but no bio text	Add a short bio near the byline
No Person schema	Add Person markup with name, job title, and sameAs
Person schema but no verified sameAs	Link the author to a real LinkedIn, X or ORCID profile
YMYL page, no credentials	State the author’s relevant credentials
YMYL page, no named reviewer	Add a “Reviewed by” name
No gov, edu or institutional links	Cite at least one primary source
No citation language	Use phrases like “according to” near key claims
Few distinct external domains	Cite a wider mix of independent sources
No date, or a date over 365 days old	Show or refresh the date
No phone or WhatsApp link	Add a real contact channel
No terms link	Add a terms page
No first-hand language	Add “I tested” style statements, if they are true
Only stock images	Use original photos or screenshots
Fewer than five specific details	Add numbers, prices, distances and timeframes
Medium or high AI risk	Add examples and a distinct voice

The technical suggestions follow the same pattern. They cover the meta description, its length, the canonical tag, Article schema and thin content.

Ready-to-paste schema

Two gaps are easier to fix with code than with advice. So the scanner writes the JSON-LD for you.

If the page has no Person schema, it builds a Person block. If the page has no Article schema, it builds an Article block. It fills in what it can read from the page: the headline from the Open Graph title, the image, the site name, the canonical URL, and the author name from the byline.

Here is a Person block as it appears in the popup.

{
  "@context": "https://schema.org",
  "@type": "Person",
  "name": "AUTHOR NAME HERE",
  "jobTitle": "JOB TITLE / ROLE HERE",
  "sameAs": [
    "https://www.linkedin.com/in/REPLACE-ME",
    "https://x.com/REPLACE-ME"
  ]
}

The dates in the Article block are placeholders in the format YYYY-MM-DDTHH:MM:SS+00:00. The scanner cannot know your real publish date, so it does not guess.

Each block has a Copy button. You fill in the placeholders and paste it inside a script tag of type application/ld+json in your page head.

Then test it. I do not trust my own snippets blindly, and neither should you. Run the page through Google’s Rich Results Test before you publish.

History, badge and export

A single scan is a snapshot. Real SEO work is a loop: fix, rescan, compare. These three features support that loop.

Score history

Every scan saves two things to your browser: the time and the overall score. They are stored under the page URL, and the scanner keeps the last 20 scans for each page.

On the next scan of the same page, the popup shows a line like this:

“Previous scan: 57 (2 days ago), now 64 (+7), scan #3 for this page.”

On a first visit, it says “First recorded scan for this page.” That tiny line answers the question I kept asking myself: did my change help?

Toolbar badge

After each scan, the score appears on the extension icon. Green means 75 or more. Amber means 50 to 74. Red means below 50.

One detail to know. The badge is set for the whole extension, not for one tab. So it keeps showing the last score even after you switch tabs. Treat it as a reminder of the last scan, not a live reading of the current page.

Report export

Two buttons sit at the bottom of the results.

• Copy Report puts a Markdown report on your clipboard.
• Download .md saves the same report as a file named like eeat-report-example-com-2026-10-16.md.

The report holds the page title and URL, the overall and pillar scores, the technical score, the AI-risk level, every suggested fix as a checkbox, and the insights. Paste it into a ticket, a client email or a task board.

The report does not include the schema snippets. Those you copy from their own boxes.

Privacy and permissions

An extension that reads pages deserves hard questions. So here are the facts, as the code and the manifest state them.

What it requests

Permission	Why it is there
activeTab	To work with the tab you are looking at when you click the icon
storage	To save score history in your own browser
downloads	To save the Markdown report as a file

It also loads a content script on every HTTP and HTTPS page. That is how it can read a page when you ask. Because of this, Chrome shows a broad warning at install time, along the lines of “read and change all your data on all websites”.

I want to be direct about that warning. It looks alarming, and it describes the access level, not the behavior. The scanner does nothing until you click “Scan This Page”. Then it reads the page and sends the result to the popup. It never changes the page.

I also removed an unused “scripting” permission in version 0.4.1. It was never needed, so it should not be there.

What it never does

• It makes no network requests. Nothing is uploaded, and nothing is sent to a server of mine.
• It has no account, no analytics, and no tracking.
• It does not modify the page.
• It does not fetch your links to check them.

What it stores

Only the history described above: a URL, a timestamp, and a score, saved with chrome.storage.local. It never clears itself. Remove the extension, or clear its data, to wipe it.

The code is plain JavaScript with no build step and no bundled libraries. Open content.js and read it. That is the best privacy policy I can offer.

How to install and use it

The extension is not on the Chrome Web Store. You load it yourself. It takes about a minute.

1. Unzip the file. You should see a folder holding manifest.json, content.js, and the popup files.
2. Open chrome://extensions in Chrome.
3. Switch on Developer mode, top right.
4. Click “Load unpacked”.
5. Choose the folder that contains manifest.json. Not the zip, and not a parent folder.
6. Click the puzzle icon and pin the shield.
7. Open any article. Click the shield, then “Scan This Page”.

It works in other Chromium browsers too, such as Edge and Brave, using their own extensions page.

Troubleshooting

• “Couldn’t reach this page.” Reload the tab, then scan again. Tabs that were open before you installed the extension have no content script yet.
• “Unsupported URL type.” Only http and https pages can be scanned. Chrome’s own pages and the Web Store are off limits.
• After an update. Click the reload arrow on the extension card, then reload the page.

For the full steps, see the Chrome guide to loading an unpacked extension.

How to read your scores

Do not chase the big number. It is a weighted blend, and it hides detail.

Start with the four bars. A page at 57 with Authoritativeness at 20 has one clear job: add real sources. The suggestions list tells you the order.

Use these rough bands for the overall score.

Score	Meaning
75 and above	Strong visible signals. Fine-tune.
50 to 74	A decent base with clear gaps. Work the suggestions.
Below 50	Key trust signals are missing. Start with byline, sources, and date.

The ceiling is about 97. No page earns a perfect score, by design.

Two habits make the tool far more useful.

• Compare pages, not just scores. Scan your page and a competitor’s page that ranks above it. Look at which bars differ.
• Rescan after every change. The history line tells you if the change moved anything.

And always read the limits in the next section before you trust a result.

What it does not do

This is the section I most want you to read. An SEO tool you trust too much is worse than no tool.

The scanner checks whether signals are visible. It does not check whether they are true. Everything below follows from that one fact.

It cannot verify truth

• It cannot tell if an author really has the credentials they claim. The word “certified” in the text counts, even if it is false.
• It cannot tell if a cited source supports the claim next to it. A link to a .gov page earns points even if the page is unrelated.
• It cannot tell if a photo is original. Stock detection looks only at the image host, so a stock photo re-uploaded to your own domain passes.
• It cannot check that a first-person story really happened.
• It cannot read rankings, backlinks, brand searches, or real user behavior. Those shape Authoritativeness in the real world, and I have no access to them.

It is not Google

Google has said that E-E-A-T is not a single ranking factor. It is a framework that raters use to judge quality, and it informs how systems are tuned. So no score from any tool, mine included, predicts a ranking. A 90 does not guarantee page one. A 40 does not doom a page.

Known false positives and misses

I found these by testing. Several I confirmed in a real browser. They are still open.

• Plural keywords. The niche detector matches exact forms. A page full of “permits” and “visas” can stay “general”. I confirmed this.
• “By Air” counts as a byline. A capitalised heading like “By Air” or “By Road” near the top can pass as an author name. I confirmed this too.
• Blunt class stripping. The scanner removes any element whose class contains words like share, related, comment, popup, modal, cookie or sidebar. A wrapper called “shared-hero” that holds your real byline gets cut out. I confirmed that, and the byline was lost.
• Long pages look “medium” for AI risk. The vocabulary measure falls with length. About 3,200 words of ordinary prose scored 0.22 and landed on medium.
• Filler phrases are not proof. Humans write “furthermore” too.
• Date guessing. The scanner prefers the article modified time, then the published time. If a page has neither, it falls back to the first time tag, which can be a comment date.
• The Person node is not tied to the article. If a page has a Person schema block for someone else, such as a team member, it still counts as author schema.
• Exact schema names only. A LocalBusiness block does not count as Organization. Only the exact type names match.
• Markup without whitespace. A byline built as an inline span and a link with no space between them can fuse into one word and be missed.
• Subdomain links count as external. A link from www.site.com to blog.site.com reads as a separate domain.
• English only. Every phrase list assumes English text.
• Only 16 institutions. The institution list is short. A respected source not on it earns nothing in that line.
• Domain rules are narrow. A .gov.np, .gov.uk or .edu.au link counts as government or education. A .ac.uk link does not.

Limits of scope

• It scans one page at a time. There is no site crawl and no bulk mode.
• It reads the page as your browser rendered it. Content that loads after you click scan may be missed, so wait for the page to finish loading.
• It scores signals, not writing quality. It will not tell you if the article is helpful, original or correct.
• Scores are capped on purpose. Authoritativeness tops out at 90 and Trust at 95. The overall score tops out near 97.
• The score is my model. The weights are my judgment calls, informed by Google’s public guidance. Another sensible builder would pick different numbers.

Use it the way you would use a checklist before a flight. It catches what you forgot. It does not fly the plane.

Testing it on real pages

I started with two real pages from the Nepal travel niche, where I work.

Page	Overall	Experience	Expertise	Authoritativeness	Trust
accessnepaltour.com, solo trekking in Nepal	57	55	60	20	85
magicalnepal.com, Machhapuchhre blog	59	30	75	50	85

Those scores came from an early version. They showed the pattern I wanted: strong Trust, weak sourcing, patchy first-hand proof. They also showed the tool’s mistakes.

I have not rescanned these two pages with 0.4.1, so I will not claim new numbers for them.

Bugs the real pages exposed

• The .gov check missed .gov.np. I had matched the end of the domain. Nepal’s government sites end in .gov.np, so they scored zero. Now the scanner reads the hostname labels.
• A plain-text byline was invisible. Many sites write “By Name” as text, with no schema. I added a plain-text fallback.
• A big menu pushed the byline out of range. I was reading the first 1,500 characters of the whole body. A mega-menu used them all. The scanner now scopes to the article or main area first.
• “Visa” matched inside “advisable”. Keywords now use word boundaries.

Bugs found while checking 0.4

I then built small test pages and ran the old and new code in real Chromium. These bugs were mine, and they became version 0.4.1.

Test page	Version 0.4	Version 0.4.1
Author linked only through an Organization’s Facebook page	Author counted as verified	Not verified. Only a Person node counts.
Valid Person schema in the JSON-LD	Not found	Found
Ordinary phrases like “by the”	Counted as a byline and a reviewer	Ignored. A capitalised name is required.
Plain-text byline	Missed	Found
Name followed by a new sentence	Captured “Samita Maharjan. Trekking permits”	Captured “Samita Maharjan”
Page with an old comment date and a fresh modified time	Age read as 2,845 days	Age read as 6 days
First-person count on a short page	1	4
Specific details such as prices and percentages	3	5

There were also two quieter fixes. Domain checks now compare the whole hostname, so a link whose address only contains a trusted name, such as sun.org inside a longer domain, no longer counts as that institution. And I removed the unused scripting permission.

The bug I did not expect

The worst one was invisible. The scanner clones the article, strips the clutter, and reads the text. But text read from a detached copy loses its line breaks.

On minified HTML, where tags sit side by side with no spaces, neighboring words fused. A byline and the sentence after it became one long word. Byline, first-person and word-count checks all failed.

In a test with minified markup, the byline went from missed to found, the first-person count from 0 to 2, and the extracted name came out as “Dr. J. R. Smith”. The fix is a block-aware text reader that inserts a break at every block tag.

The lesson is simple. Pages differ from your test pages. Build fixtures that look like the ugly ones.

Every scan in these tests ran with no page errors. That does not make 0.4.1 bug-free. The previous section lists what I know is still wrong.

Roadmap

These are plans, not promises. They follow the known limits.

1. Length-aware vocabulary check. Compare a fixed sample size, so long pages stop being read as medium risk.
2. Plural and stem matching for the niche keywords, and a longer list for each vertical.
3. Narrower permissions. Inject the scanner only when you click, so Chrome’s broad install warning can go.
4. A smarter byline test. Reject phrases like “By Air” and tie a Person schema block to the article it belongs to.
5. Safer cleaning. Strip clutter by element role and position, not by a class substring.
6. More schema types. Accept subtypes such as LocalBusiness as organizations.
7. A side-by-side mode to compare your page against a competitor’s.
8. Other languages for the phrase lists.
9. A Web Store listing, once the permission story is clean.

If you try it and it gets a page wrong, that is the most valuable thing you can tell me. Send the URL and what you expected.

FAQ

What is an EEAT checker?

It is a tool that looks for visible signs of Experience, Expertise, Authoritativeness, and Trust on a page. Mine does this inside your browser and reports a score for each.

Is the EEAT Signal Scanner an official Google tool?

No. It is an independent project. Google does not publish an E-E-A-T score, and Google has said E-E-A-T is not a direct ranking factor.

Will a higher score improve my rankings?

Not by itself. The score tells you which trust signals are missing. Adding them can make a page more credible to readers. Rankings depend on far more than this.

Does it send my data anywhere?

No. It makes no network requests. History is stored locally in your browser.

Is it free?

Yes. This version is free.

Why is it not in the Chrome Web Store?

It is a new project, and I have not submitted it. You load it as an unpacked extension.

Can it tell me if content is AI-written?

No. It reports a rough risk level based on filler phrases, sentence rhythm, and vocabulary. It can be wrong in both directions.

Can I scan a competitor’s page?

Yes. It works on any public HTTP or HTTPS page you can open. Comparing their bars with yours is one of the best uses.

Why does my page get a low Authoritativeness score?

That pillar rewards links to government, education, and recognized institutional sources, and phrases that show you cite them. It cannot see backlinks, so a page with strong real-world authority can still score low.

Does it work in Edge or Brave?

It should, since they run Chromium and support Manifest V3 extensions. I have tested it in Chromium.

Why does the toolbar badge show the wrong number?

The badge is global, not per tab. It shows the last scan you ran.

How do I report a wrong result?

Send me the page URL, the score you saw, and the score you expected. Real pages are what make it better.

Final thoughts

An EEAT checker will not make your content trustworthy. Only real people, real evidence, and real care can do that.

What a good EEAT scanner does is show you where the evidence is thin. It points to the missing byline, the stale date, the unsourced claim. Then you fix the substance.

That is why I built the scanner to be checkable. It runs in your browser, sends nothing out, and every point can be traced in the code. Test it on pages you know. Keep your trust basics tight. And remember that the score is a map, not the destination.