Knowledge Base

The WebYes knowledge base explains the terms that show up in the scan and the mark. Not a loose buzzword list, but guides that help you read a report: why LCP matters, what a security header does, when WCAG 2.2 AA applies, and how mobile-friendliness lands in the scorecard.

Each guide maps to at least one of the four pillars: speed, security, mobile and accessibility. Detail pages include definitions, working examples, FAQs and sources to primary documentation (W3C, web.dev, Digitoegankelijk, internet.nl).

Use the knowledge base before you optimise. First understand which pillar is holding you back, then change plugins or CDNs. That stops you spending days on cosmetic fixes while HTTPS or viewport still fails.

Search sits at the top. Type a term (for example CSP or Core Web Vitals) and cards filter live. Clear the query to return to the default layout: featured, guides and (where applicable) short terms.

Featured shows the guides that most often sit next to a first scan. Guides are longer explainers with steps and pitfalls. Terms are shorter definitions; that group fills as we publish term pages.

Each card links to a full SSR page with sources. The hub is the entry: choose the topic here, read the depth there. Internal links between guides (for example from speed testing to Core Web Vitals) live in those page texts.

The free scan scores the same four pillars as the mark. Average 80 or higher with no pillar below 60 and you qualify for the mark. The knowledge base turns those thresholds into plain language: what a security score of 58 means, or why mobile below 60 blocks the badge despite a high speed score.

Automated accessibility checks cover an estimated 30-50% of WCAG criteria. That is also on the how-it-works page. Guides on WCAG, the European Accessibility Act and the accessibility statement explain where the machine stops and a human audit starts.

Security guides point to concrete headers (HSTS, CSP) and to internet.nl for Dutch internet standards. Speed guides stay close to Core Web Vitals (LCP, INP, CLS) as Google documents them, without promising lab scores equal field data.

Stay on the knowledge base when you need to grasp a term or a checklist before a redesign. Start the free scan when you want to know where your domain stands now. The scan does not replace the guides: it points at problems; the guides explain why those problems exist.

After a scan you typically open the guide for the weakest pillar. Security red from missing headers? Start with security headers and SSL. LCP too high? Read Core Web Vitals and website speed testing. That creates a short path from finding to fix.

For timely updates (product news, scan live, annual report) use the blog. The knowledge base stays evergreen: we revise guides when standards or our engine change, not to chase news.

Claims about standards link to primary sources. WCAG at the W3C, Web Vitals on web.dev, legal accessibility frames at Digitoegankelijk and ACM. WebYes product facts (six pages free, fifteen full, 80/60 thresholds, re-audit around thirty days) are product facts, not external citations.

We do not copy competitor copy and we do not fill a guide with generic AI padding. Each page should stand on its own for someone reading a report beside the guide.

Missing a term? Email [email protected] or use the contact form. New guides land here once they meet depth and source requirements.

Score under 80 or a pillar under 60? Open the guide for that pillar first, not every card at once. Note the top findings from the report (severity first) and search those terms in the hub search field.

When a fix clears a finding, rescan outside the sixty-minute dedupe window. If the score still sticks, read the how-it-works page on what the machine does not cover, especially accessibility. That stops endless tweaking on issues only a human audit can tick off.

For teams: share one guide URL per sprint item. The knowledge base is shared language between developer, marketer and owner, not a replacement for your issue tracker.