On-Page SEO Auditor - required inputs

Paste your URLs, one per line, into the required urls_to_audit project setting before launching. The bot works through the list with up to four concurrent workers, and every dataset records a Page_URL column so rows stay attributable to the page they came from. Results are de-duplicated per URL.

Nine datasets per page: HTTP response and indexability (status, redirects, robots directives, canonicals, charset, viewport, cookies, security headers with a letter grade); on-page elements (title and meta description with pixel-width truncation checks, heading structure outline, hreflang, Open Graph and Twitter card scoring); content readability (word counts, six readability formulas, text-to-HTML ratio, keyword-density flag, placeholder-text detection); a full links census (internal versus external counts, rel values, anchor-text quality, insecure targets); media and performance (image alt coverage, missing dimensions as a layout-shift risk, modern-format coverage, render-blocking scripts and stylesheets, DOM size and depth, TTFB); structured data (JSON-LD validity, schema types, rich-result eligibility, Microdata and RDFa census); an AXE accessibility audit with severity counts and a grade; and two triage views, Critical_Issues and Healthy_Pages.

Yes, in depth. The Response_Indexability dataset records the meta robots content, the X-Robots-Tag response header, every robots directive parsed out (noindex, nofollow, noarchive, nosnippet, max-snippet and friends), the source of any noindex signal, canonical count, whether the canonical is self-referencing and absolute, where it resolves to, and a canonical verdict listing concrete issues such as missing, multiple, relative, cross-host or pointing elsewhere. A combined indexability verdict names every blocker found, including meta refresh and non-HTML content types.

The Content_Readability dataset computes Flesch Reading Ease, Flesch-Kincaid grade, Gunning Fog, SMOG, Automated Readability and Coleman-Liau from the rendered body text, plus average sentence length, syllables per word, unique-word ratio and estimated reading time. It flags pages as thin when the word count falls below the low_content_words setting (300 by default), classifies length from Empty to Long-form, reports the top non-stopword terms with a keyword-stuffing density verdict, and detects leftover lorem ipsum or placeholder text.

Yes. The audit_accessibility step runs the AXE engine over the whole document and stores violations, passes and incomplete checks; the Accessibility_AXE dataset then reports counts by severity (critical, serious, moderate, minor), affected nodes, the specific violation ids, WCAG and best-practice tags, a pass-rate score and a letter grade. The step is wrapped in error handling: if the engine cannot run because of a content security policy, a blocking rule or an unreachable engine source, the output says so explicitly instead of pretending the page passed.

Critical_Issues is a filtered triage view containing only pages that fail at least one hard check: HTTP status 400 or above, a title count other than one, an H1 count other than one, more than one meta description, more than one canonical, a missing viewport tag, noindex present in meta robots or the X-Robots-Tag header, more than 25 percent of images missing alt text, or a DOM larger than 1500 nodes. An empty Critical_Issues file after a run is the good-news outcome.

There is no built-in cap on the list length; the practical bounds are your patience and the target server's tolerance. The bot audits with up to four concurrent workers, and each page navigation allows 60 seconds before it is caught, logged and skipped. For large lists, audit in batches and keep an eye on rate-limit responses in the Status_Code column.

Speed and bandwidth. The configuration blocks image, media, font, stylesheet, websocket, manifest, texttrack, eventsource and other network requests, because the audit reads the DOM, response headers and HTTP metadata rather than pixels. Image tags and their attributes are still fully analysed for alt text, dimensions, lazy loading and formats - only the binary downloads are skipped. The trade-off is that the bot cannot judge visual rendering, so screenshot-dependent checks are out of scope.

No. The bot audits exactly the URLs you submit in the urls_to_audit setting and nothing more; it does not discover pages, follow internal links or parse sitemaps. That is deliberate: an audit list you control is predictable, polite to the server and defensible. If you need discovery, generate the URL list from your own sitemap or analytics export first, then feed it in.

Yes. The Structured_Data dataset counts and parses every JSON-LD block, records parse errors verbatim, walks nested nodes and graphs, and lists all schema types found with counts. It sets flags for Organization, LocalBusiness, WebSite, WebPage, BreadcrumbList, Article, Product, FAQ, HowTo, Review, AggregateRating, VideoObject, Event, Person and Speakable, and produces a rich_result_eligible summary naming the enhancements the page qualifies for. A separate Microdata_RDFa census reports itemtype, itemprop, typeof and property usage so mixed-format markup is visible.

The Content_Readability dataset fingerprints each page's normalised body text with a full content hash and a 64-bit simhash built from three-word shingles, and exposes an eight-character near_duplicate_key. After a run, sort or group that column across your URL list: pages sharing a near-duplicate key have substantially similar body text, which is how you find template duplicates, boilerplate-heavy pages or canonicalisation candidates without eyeballing every file.

Yes on first run: the launcher fetches its configuration by id from the backend at launch, so an internet connection is required at least the first time it starts.

No. The downloaded file must keep its exact name - the filename carries the per-bot configuration id, and renaming it breaks the configuration fetch at launch.