Documentation
Issue documentation
Every issue Plaincheck detects — what it is, why it matters, and what to do about it.
docs
Accessibility Checks: What Probeo Observes
Probeo performs automated structural analysis against a subset of WCAG 2.1 criteria. It identifies violations that are deterministic and machine-verifiable: missing alternative text, insufficient color contrast, unnamed interactive elements, absent form labels, and invalid ARIA attributes. Automated checking reliably detects roughly 30% of WCAG issues. The remaining 70% requires manual evaluation, user testing, or contextual judgment that no crawler can replicate.
Fix Missing Form Labels, Conflicting Labels, and Required Attributes (WCAG 1.3.1)
Form controls depend on programmatic label associations to be usable by assistive technology. Three failure patterns recur across most codebases: inputs with no label at all, inputs with multiple conflicting labels, and required fields that lack the HTML5 required attribute or aria-required. Each creates a different kind of breakdown. Missing labels leave screen reader users unable to identify what a field expects. Multiple labels cause assistive technology to announce one label while sighted users may see another — the mismatch is silent. Missing required attributes suppress native validation and prevent screen readers from communicating that a field is mandatory before submission fails. WCAG 1.3.1 (Info and Relationships) requires that relationships between labels and controls be programmatically determinable.
Fix Missing Image Alt Text for Accessibility (WCAG 1.1.1)
The alt attribute on images serves as the text-level equivalent of visual content. When the attribute is missing entirely, screen readers fall back to announcing the file name — often a hash, a CMS slug, or a path fragment that communicates nothing. When the attribute is present but empty on an informative image, the image is treated as decorative and skipped. Both cases create a gap between what sighted users see and what assistive technology can convey. WCAG 1.1.1 requires that all non-text content has a text alternative that serves the equivalent purpose.
Buttons and Links Missing Accessible Names
Interactive elements require a computed accessible name so assistive technology can identify them. Browsers calculate this name from a defined sequence: text content, then aria-label, then aria-labelledby, then title attribute. When none of these sources produce a string, the element has no name. Screen readers announce it as an unlabeled button or link. Keyboard users encounter a focusable element with no indication of what it does. The two most common violations — button-name and link-name — share this root cause.
Fix Insufficient Color Contrast for WCAG Compliance
Color contrast measures the luminance difference between foreground text and its background. WCAG 2.1 defines minimum contrast ratios: 4.5:1 for normal text and 3:1 for large text at the AA level. When contrast falls below these thresholds, text becomes functionally invisible to users with low vision, color deficiencies, or anyone reading in suboptimal lighting. This is not an edge case. Roughly 1 in 12 men and 1 in 200 women have some form of color vision deficiency. Insufficient contrast is one of the most frequently detected accessibility violations across the web.
Content Quality: Readability Measurement and Analysis
Probeo's content quality analysis measures readability using established formulas that quantify structural text properties: sentence length, syllable density, word familiarity, and character count. These formulas produce scores that correlate with reading difficulty under controlled conditions. They do not measure whether content is clear, accurate, well-organized, or appropriate for its audience. Readability scores are observability data, not quality verdicts.
How to Fix CF-Cache-Status Header | Probeo
The CF-Cache-Status header is added automatically by Cloudflare to indicate whether a response was served from cache. The header discloses that the site is using Cloudflare as a CDN or proxy. This information is visible to clients, crawlers, and anyone inspecting HTTP traffic.
How to Fix CF-Ray Header | Probeo
The CF-Ray header is added automatically by Cloudflare to uniquely identify each request as it passes through Cloudflare infrastructure. The header confirms the use of Cloudflare and provides a request identifier that can be used to correlate traffic patterns or infrastructure topology.
Should I Use X-Frame-Options or CSP frame-ancestors? | Probeo
X-Frame-Options and Content-Security-Policy frame-ancestors both control whether a page can be embedded in an iframe. The frame-ancestors directive is more flexible and is the modern replacement. When both are present, browsers that support CSP Level 2 or higher ignore X-Frame-Options.
Performance Measurement: Lab Data, Field Data, and Structural Risk
Performance measurement splits into two fundamentally different data sources: lab data collected in controlled environments, and field data collected from real users. Each answers different questions. Probeo uses structural analysis to identify patterns that reliably predict poor performance outcomes, regardless of which data source confirms them.
Core Web Vitals: CLS, INP, and LCP Risk Levels
Core Web Vitals are three metrics Google uses as page experience ranking signals: Cumulative Layout Shift (CLS) measures layout stability, Interaction to Next Paint (INP) measures responsiveness, and Largest Contentful Paint (LCP) measures loading speed. Each metric has defined thresholds that classify pages as good, needs improvement, or poor. Probeo evaluates structural risk factors for each metric based on page composition rather than synthetic test runs.
Page Weight and Image Optimization for Web Performance
Page weight and image optimization are resource-level issues, distinct from metric-level indicators like Core Web Vitals. A metric tells you something is slow. A resource issue tells you why. Total page weight determines how long a page takes to become usable, but the severity depends on the connection. A 3 MB page loads in under a second on broadband and stalls for 8+ seconds on a 3G connection. Images typically account for 40-60% of total transfer size, making them the single largest optimization surface on most pages.
Clickjacking Protection Gaps: Missing Framing Controls and XFO Override by CSP
Two distinct failure patterns leave pages vulnerable to clickjacking despite apparent configuration. The first is complete absence: neither Content-Security-Policy frame-ancestors nor X-Frame-Options is present, so browsers impose no framing restriction at all. The second is silent override: X-Frame-Options is set, but a Content-Security-Policy header with frame-ancestors is also present, and browsers discard XFO entirely per the CSP specification. If that frame-ancestors value is permissive or absent from the directive, the restrictive XFO value has no effect.
Block Clickjacking with Frame-Ancestors Directive
Clickjacking occurs when a page is embedded in an iframe and positioned to trick users into clicking interface elements they cannot see. Without frame embedding restrictions, any site can load the page in a frame. The frame-ancestors CSP directive controls which origins can embed the page, preventing unauthorized framing.
CSP Configuration Issues: Meaningless Policies, Multiple Headers, Deprecated Directives, HTTP Sources
A Content Security Policy can exist in the response without restricting anything. Policies composed entirely of reporting directives, fetch directives with overly broad values, or deprecated header names create the appearance of security controls without providing them. Multiple CSP headers interact through intersection semantics that tighten rather than merge policy, producing unexpected blocking. HTTP sources in policies served over HTTPS reintroduce the attack surface that encryption was meant to eliminate. Each of these configuration errors is worse than having no CSP at all, because the presence of the header signals resolved intent.
Prevent Base Tag Hijacking and Form Action Redirection with CSP
CSP provides directives beyond script-src that prevent injection attacks operating outside script execution. base-uri controls which URLs the <base> element can set, preventing relative URL hijacking. form-action controls where forms can submit data, preventing credential exfiltration through action attribute injection. Both directives are absent from most policies because teams focus on script-src and assume other injection vectors are covered.
CSP object-src Directive: Block Plugin and Embed Abuse
The object-src directive controls which sources can serve content for object, embed, and applet elements. When missing from CSP, the browser falls back to default-src or permits all sources. When set to a wildcard, any origin can load plugin content. Both conditions allow attackers to embed Flash SWFs, Java applets, or other plugin-based payloads that execute outside normal script sandboxing. Setting object-src to 'none' eliminates this class of attack with no practical cost on modern sites.
Move from Report-Only to Enforced Content Security Policy
Content-Security-Policy-Report-Only sends violation reports without blocking resources. The header allows observation of policy impact before enforcement. Moving to enforced mode replaces the report-only header with Content-Security-Policy, causing browsers to block violations rather than report them. Report-only mode is a staging mechanism, not a permanent configuration.
Missing or Wildcard CSP script-src Directive
The script-src directive is the most security-relevant part of any Content Security Policy. It controls which origins can deliver executable JavaScript. When script-src is missing, the browser falls back to default-src. If default-src is also absent or set to a wildcard, all script sources are permitted. A wildcard script-src (* ) explicitly allows scripts from any origin. Both conditions reduce CSP to a cosmetic header with no meaningful script restriction.
Stop Cross Site Scripting (XSS) with Content Security Policy
Cross-site scripting occurs when untrusted content executes as code in the page context. Without restrictions, browsers execute any script element regardless of origin. Content Security Policy defines which sources can provide executable code. A strict CSP prevents injected scripts from running even when output encoding fails.
Fix CORS Misconfiguration: Wildcard Origins, Credentials, Null Origin, Vary Header
CORS controls which origins can read responses from cross-origin requests. Misconfigurations fall into four patterns: wildcard origin with credentials enabled, unrestricted wildcard origin, null origin allowed, and missing Vary: Origin header. Each weakens isolation differently. Wildcard with credentials is the most severe because it permits credential theft from any origin. The others create data exposure, sandbox bypass, and cache poisoning conditions respectively.
Remove Framework and Server Headers to Reduce Information Disclosure
Framework and server headers like X-Powered-By, Server, X-AspNet-Version, and X-AspNetMvc-Version appear in HTTP responses. These headers identify web servers, application frameworks, and runtime environments. They often include version numbers. Attackers use this information to identify known vulnerabilities in specific versions. Removing these headers reduces information available for reconnaissance. The headers provide no functional value to browsers or clients. Elimination is a standard hardening practice.
Disable MIME Sniffing by Setting X-Content-Type-Options nosniff
MIME sniffing is browser behavior that attempts to determine content type by examining file contents rather than trusting the Content-Type header. Browsers inspect byte patterns to detect HTML, scripts, images, and other formats. This override creates security vulnerabilities when user-uploaded content or untrusted sources serve files with incorrect Content-Type headers. The X-Content-Type-Options header with nosniff value disables this behavior. Browsers then respect declared Content-Type headers without inspection or override.
Set Referrer-Policy to Control URL Information Sent to External Sites
Referrer-Policy controls how much URL information the browser sends in the Referer header when navigating to another page or loading external resources. Without a policy, the browser decides what to send. Older browsers default to sending the full URL, including path, query parameters, and fragments. This exposes internal URL structures, search queries, session tokens in URLs, and authenticated paths to any destination server or intermediary.
Prevent Framework Leaks via the Vary Header
The Vary header specifies which request headers affect response caching. Framework-specific Vary values expose implementation details. Headers like X-Requested-With or Accept-Language combinations that are unique to specific frameworks create fingerprints that reveal the underlying technology stack.
Prevent Version Information Leaking Through Headers and Responses
Version information leaks through HTTP headers, error messages, HTML comments, JavaScript files, and meta tags. Server headers include version numbers like Server: nginx/1.18.0. Framework headers show versions like X-Powered-By: Express 4.16.0. Error pages display stack traces with library versions. HTML generators add meta tags identifying CMS versions. Attackers use version data to identify known vulnerabilities. Preventing version leaks requires configuration changes across multiple layers and careful review of responses.
Set X-Content-Type-Options to Prevent MIME Sniffing
The X-Content-Type-Options header controls browser MIME type interpretation. Without this header, browsers may ignore the declared Content-Type and attempt to guess the file type from content. This behavior creates security risks when user-controlled content is served or when Content-Type headers are misconfigured.
Set X-Frame-Options Correctly to Control Frame Embedding
X-Frame-Options controls iframe embedding at the HTTP header level. The header accepts three values: DENY prohibits all framing, SAMEORIGIN allows same-origin framing, and ALLOW-FROM specifies a single allowed origin. Incorrect values or missing headers permit unauthorized embedding that enables clickjacking attacks.
Remove the X-Powered-By Header to Prevent Technology Disclosure
The X-Powered-By header identifies the framework, runtime, or platform serving responses. Frameworks and application servers add this header by default. The header provides no operational value but discloses implementation details. Removing it reduces information available during reconnaissance.
How to Roll Out HSTS Without Breaking Subdomains | Probeo
The HTTP Strict-Transport-Security header with the includeSubDomains directive forces browsers to use HTTPS for the domain and all subdomains. Once cached, this policy cannot be revoked by the browser. If any subdomain lacks a valid HTTPS configuration, it becomes unreachable until the max-age expires or the browser cache is manually cleared.
Fix Inline Event Handlers by Replacing with addEventListener
Inline event handlers are JavaScript expressions embedded directly in HTML element attributes like onclick, onload, onmouseover, and onerror. These handlers execute when their corresponding events trigger. Content Security Policy treats inline event handlers as inline scripts. CSP cannot distinguish between legitimate handlers and XSS payloads without unsafe-inline. The presence of inline event handlers forces unsafe-inline or prevents CSP adoption. Replacing handlers with addEventListener calls in external scripts resolves this constraint.
Fix Inline Scripts by Moving to External Files or Using CSP Nonces
Inline scripts are JavaScript code embedded directly in HTML using script tags without src attributes or event handler attributes like onclick. These scripts execute in the page context with full DOM access. Content Security Policy cannot distinguish between legitimate inline scripts and XSS payloads without additional mechanisms. Inline scripts prevent CSP deployment or require unsafe-inline which disables XSS protection. Moving scripts to external files or implementing CSP nonces resolves this constraint.
Fix Mixed Content by Upgrading HTTP Resources to HTTPS
Mixed content exists when an HTTPS page references resources loaded over HTTP. Browsers categorize mixed content as active or passive. Active mixed content includes scripts, stylesheets, and iframes that can modify page behavior. Passive mixed content covers images, audio, and video. Modern browsers block active mixed content and warn about passive mixed content, degrading security guarantees and user trust.
Eliminate unsafe-eval from CSP by Removing eval and Dynamic Code Execution
The unsafe-eval directive appears in Content Security Policy script-src declarations. It permits eval(), Function constructor, setTimeout with string arguments, and similar dynamic code execution methods. These functions convert strings into executable JavaScript at runtime. XSS attacks can exploit eval to execute injected strings as code. CSP without unsafe-eval blocks these execution vectors. Removing unsafe-eval requires refactoring code to eliminate dynamic string evaluation. The result is stricter XSS protection.
Remove unsafe-inline from CSP by Eliminating Inline Scripts and Handlers
The unsafe-inline directive appears in Content Security Policy script-src and style-src declarations. It permits all inline scripts, event handlers, and inline styles to execute. CSP with unsafe-inline provides no protection against XSS attacks that inject inline code. The directive exists as a compatibility mechanism for sites with inline scripts. Removing unsafe-inline requires eliminating inline scripts and event handlers or implementing CSP nonces. Without unsafe-inline, CSP blocks inline code execution including XSS payloads.
Fix XSS Attack Vectors: javascript: URLs, data: Script Sources, and Insufficient Protection
Three XSS vectors remain after addressing inline scripts, event handlers, and CSP unsafe-inline/unsafe-eval: javascript: URL protocol handlers, data: URIs in CSP script-src, and insufficient overall XSS protection. Each creates an execution path that standard CSP directives do not automatically block. javascript: URLs execute code through navigation and attribute contexts. data: URIs in script-src allow inline payloads encoded as base64 script sources. Together with gaps in CSP coverage, these vectors leave sites exposed even when common protections appear to be in place.
Safest HSTS Configuration for Long-Term Security
The safest HSTS configuration uses max-age=63072000 (two years), includeSubDomains when all subdomains support HTTPS, and preload for sites committed to permanent HTTPS. This configuration provides maximum protection against protocol downgrade attacks and ensures browsers never attempt HTTP connections. Lower max-age values reduce commitment but leave larger windows for attack. Omitting includeSubDomains or preload creates subdomain and first-visit vulnerabilities.
HSTS Max-Age Duration for Production Websites
HSTS max-age should be 31536000 seconds minimum for production sites and 63072000 seconds for sites eligible for preload. The max-age directive specifies how many seconds browsers enforce HTTPS-only connections. Short max-age values under one year create frequent windows where HSTS expires and downgrade attacks become possible. Two-year max-age satisfies preload requirements and extends protection duration with minimal additional risk.
Force HTTPS for All Traffic Using Redirects and HSTS
Forcing HTTPS requires two mechanisms: redirecting existing HTTP requests to HTTPS and preventing future HTTP connections. HTTP to HTTPS redirects at the server level catch initial HTTP requests and upgrade them. HTTP Strict Transport Security headers instruct browsers to use only HTTPS for subsequent visits. Together, these mechanisms eliminate HTTP traffic entirely. Partial enforcement leaves HTTP pathways active.
Ensure the page uses a UTF-8 charset declaration | Probeo
The page does not declare UTF-8 as its character encoding, or the declaration is missing entirely. Browsers and search engines rely on charset declarations to interpret byte sequences as text. Without an explicit UTF-8 declaration, the document may be interpreted using a fallback encoding that does not match the actual content. This causes rendering errors, breaks non-ASCII characters, and creates ambiguity about how the text should be displayed.
Add Required Property to JSON-LD Schema
Schema types define required properties that must be present for valid structured data. Missing a required property causes validation failure. Search engines either reject the data entirely or decline to show rich results. The structured data exists but provides no value.
Restructure JSON-LD as Valid Object or Array
JSON-LD blocks must contain either a single object or an array of objects at the root level. When the structure violates this requirement, parsers cannot process the data. The entire block fails, regardless of the validity of nested content.
Add or Fix @context in JSON-LD
The @context property establishes vocabulary mapping for JSON-LD. Without it, properties have no defined meaning. Search engines cannot interpret the data because no schema reference exists. The block remains valid JSON but meaningless as structured data.
Fix Non-Schema.org @context in JSON-LD
The @context property exists but references a URL other than schema.org. This is a different problem from missing @context entirely. The block has a vocabulary declaration, but it points to a namespace that search engines do not consume. Properties resolve against the wrong vocabulary, producing structured data that is syntactically valid but semantically invisible to Google, Bing, and other structured data consumers.
Fix Nested JSON-LD Objects Without Breaking Parent Schema
Nested objects in JSON-LD represent entity relationships. Errors in nested objects can cascade to parent entities or remain isolated depending on the error type. Fixing nested errors requires understanding both the child schema requirements and the parent's expectations for that property.
Suspicious JSON-LD Type Patterns from Themes and Plugins
Structured data generated by themes and plugins often produces type combinations that are technically valid but semantically nonsensical. A page describing a single blog post should not also declare itself an Organization, WebSite, BreadcrumbList, and WebPage in the same graph. These patterns pass Google's Rich Results Test but do not produce rich results, and at scale they indicate to search engines that the structured data is machine-generated boilerplate rather than intentional markup.
Fix JSON-LD Syntax Errors
A JSON-LD block with syntax errors cannot be parsed. Search engines skip the entire block, discarding structured data that would otherwise clarify page meaning. The condition is not a warning. It is a complete failure of interpretation.
Set Correct @type in JSON-LD
The @type property declares what kind of entity the JSON-LD block represents. Missing @type leaves the data unclassified. Wrong @type assigns incorrect entity semantics. Search engines rely on @type to determine which rich result features apply and which properties are required.
Add Lang Attribute to HTML Element for Language Identification
The html element lacks a lang attribute declaring the primary language of the page content. Without explicit language identification, browsers and assistive technologies must guess the language from content. Search engines cannot confidently determine which language audience the page targets. The lang attribute uses ISO 639-1 language codes, optionally combined with ISO 3166-1 region codes for locale specificity. Missing or incorrect lang attributes reduce accessibility and create ambiguity in language-specific search results.
Missing Meta Descriptions Reduce Search Clarity and Click Intent
A page lacks the meta description element that defines the summary text shown in search results. Search engines generate snippets from page content automatically when no explicit description exists. This generated text may not represent the page accurately or persuasively. The absence removes direct control over how the page appears in search interfaces. Meta descriptions do not affect ranking but shape click behavior and searcher expectations.
Resolve duplicate Open Graph tags causing unpredictable previews | Probeo
The page contains duplicate Open Graph meta tags for the same property. When a property like og:title or og:description appears more than once, social platforms must decide which value to use. Facebook typically reads the first occurrence. LinkedIn and Twitter may read the last. Some platforms behave inconsistently depending on the property. The result is that the same URL produces different previews depending on where it is shared, and no preview is reliably correct.
Use absolute HTTPS URLs for Open Graph properties | Probeo
Open Graph properties like og:image or og:url contain relative URLs or use HTTP instead of HTTPS. Social platforms fetch these resources to generate previews when the page is shared. Relative URLs cannot be resolved without context, and HTTP URLs may fail security requirements on platforms that enforce HTTPS. This prevents images from displaying and causes shared links to appear broken or incomplete.
Set the correct og:locale for the page's language | Probeo
The og:locale property is missing or specifies a language and region combination that does not match the page's actual language. Social platforms use og:locale to understand what language the content is written in and how to present it to users. When og:locale is absent or incorrect, platforms may misinterpret the content's language, apply incorrect localization rules, or fail to surface the page to the appropriate audience.
Add recommended Open Graph tags: og:title, og:type, og:site_name | Probeo
Three recommended Open Graph properties are absent: og:title, og:type, and og:site_name. None of these are strictly required for a social preview to render. Platforms apply fallback logic when they are missing. But fallbacks are approximations, not declarations. Without og:title, platforms extract the <title> element, which often includes site name suffixes or separator characters that look wrong in a card preview. Without og:type, the protocol assumes 'website', which is correct for homepages but misclassifies articles, products, and profiles. Without og:site_name, previews display the URL hostname instead of the brand name, losing attribution in feeds where visual identity matters.
Add missing required Open Graph tags: og:image, og:description, og:locale | Probeo
One or more required Open Graph tags are absent from this page: og:image, og:description, or og:locale. Social platforms depend on these properties to construct the preview card displayed when a URL is shared. When og:image is missing, the preview has no visual element. When og:description is missing, platforms either extract text heuristically or display nothing. When og:locale is missing, platforms assume a default language and region that may not match the content. Each missing tag degrades the preview independently, and the combined absence produces a share card that is functionally blank.
Set og:url to the canonical, public URL | Probeo
The og:url property does not match the canonical URL. Social platforms use og:url to understand which URL represents this page. When og:url diverges from the canonical URL, the page claims two different authoritative addresses. This creates ambiguity about which version is correct, causing shared links to point to the wrong location and preventing social signals from consolidating.
Add Canonical URL to Prevent Duplicate Content Confusion
A page lacks the canonical link element that specifies the preferred URL for this content. Without a canonical URL, search engines may index multiple URL variations pointing to identical or substantially similar content. This creates duplicate content signals that dilute ranking authority across URLs instead of consolidating it. The canonical tag resolves ambiguity when tracking parameters, session IDs, or alternate URL structures create multiple paths to the same content.
H1 Heading Issues: Missing and Multiple H1 Tags
The H1 element establishes the primary heading of a page. It signals the main topic to both users and search engines, and anchors the document outline that assistive technologies use for navigation. Two distinct violations occur: pages with no H1 element (missing-h1) and pages with more than one H1 element (multiple-h1). Both degrade the clarity of document structure. A missing H1 removes the top-level heading signal entirely. Multiple H1 elements create competing primary headings, flattening the hierarchy that heading levels are designed to express.
Resolve Noindex and Self-Referencing Canonical Conflict
A page declares both a noindex robots directive and a self-referencing canonical URL. These two signals contradict each other. The canonical tag asserts this URL is the authoritative version of the content and should be indexed. The noindex directive tells crawlers to exclude the page from search results entirely. Search engines receiving both signals must decide which to honor. Google has stated noindex typically takes precedence, but the conflict itself indicates misconfiguration. The page is either meant to be indexed or it is not. Both cannot be true simultaneously.
Title Tag Rules for Search Engines and Browser Display
The title element defines the page name shown in browser tabs, search results, and bookmarks. Valid title tags require specific structural properties and content characteristics. Each page must have exactly one title element within the document head. Title text must be unique across the site, concise enough to display without truncation, and descriptive of page content. Violations include missing titles, duplicate titles across pages, excessive length, or generic placeholder text.
Add Viewport Meta Tag for Mobile Device Display Control
The page lacks a viewport meta tag controlling mobile device display behavior. Without viewport configuration, mobile browsers render pages at desktop widths and scale them down to fit small screens. Text becomes unreadably small and users must pinch-zoom to interact with content. The viewport meta tag instructs browsers to match the page width to the device screen width and maintain readable scale. Missing or incorrect viewport tags prevent responsive designs from functioning correctly on mobile devices.
Move X-Robots-Tag from HTML Meta to HTTP Headers for Non-HTML Resources
Robots directives can be specified through HTML meta tags or HTTP headers. HTML meta robots tags work only for HTML documents and require parsing the page content. The X-Robots-Tag HTTP header applies to all resource types including PDFs, images, and other non-HTML files. Header-based directives reach crawlers before content parsing begins. Moving directives from HTML to HTTP headers enables control over non-HTML resources and centralizes robots policy at the infrastructure level.
Expand thin content to provide value and context | Probeo
The page contains insufficient substantive text relative to its purpose. Search engines rely on textual content to understand relevance, establish context, and determine ranking eligibility. When a page lacks meaningful text, it becomes difficult to distinguish from placeholder pages, low-effort aggregation, or navigation elements. This reduces confidence that the page provides unique value, which affects ranking potential and crawl prioritization.
JSON-LD Syntax Errors Block Schema Validation
A JSON-LD block contains syntax that prevents parsing as valid JSON. The structured data cannot be read by search engines. The block is present in page source but functionally invisible.
Content Quality
Aggregate Readability Scores: Overall Ease, Readability, Grade Difficulty, and Composite Difficulty
Aggregate readability scores combine the outputs of multiple individual formulas into composite metrics. Four aggregate scores exist: Overall Ease Score, Overall Readability Score, Grade Difficulty Score, and Composite Difficulty Score. Each aggregation method addresses a specific limitation of relying on any single formula. Individual formulas disagree because they weight different text features. Aggregate scores absorb that disagreement into a more stable signal.
Readability Formula Scores: Flesch-Kincaid, Gunning Fog, SMOG, and More
Readability formulas estimate text complexity by analyzing surface features of writing: sentence length, syllable count, word familiarity, and character density. Seven formulas are commonly applied to web content. Each uses different inputs and produces different scales. No single formula captures comprehension difficulty completely, because comprehension depends on domain knowledge, context, and reader intent, none of which these formulas measure.