Overview
The On-Page SEO Auditor is an on-page SEO auditor: a standalone desktop bot that visits every URL you hand it and measures each page across nine audit datasets - indexability and HTTP response, on-page elements, content readability, a full links census, media and DOM performance, structured data, an AXE accessibility audit, and two triage views that separate critical issues from healthy pages. Each dataset lands in its own CSV output named after the dataset, beside the launcher, so a run over fifty URLs produces fifty comparable rows per file and nothing is trapped inside a vendor dashboard.
What does the On-Page SEO Auditor do?
You supply a list of URLs in the required urls_to_audit project setting, one per line, and the bot works through it with up to four concurrent workers. It starts from a blank page rather than pre-navigating, so every fetch happens inside the audited command flow where the response metadata - status, final URL, redirect chain, headers, protocol, timing - can be captured per page. To keep runs fast it blocks image, media, font, stylesheet, websocket, manifest, texttrack, eventsource and other network requests; the audit reads the DOM and HTTP layer, not pixels. Thresholds are settings variables you can adjust before a run: title_pixel_limit (580, the SERP title cutoff in Arial 20px), desc_pixel_limit (990, the meta description cutoff in Arial 14px), low_content_words (300, below which a page is flagged thin) and max_outbound_links (100, above which outbound linking looks like a link farm). Because everything executes on your machine, the URL list you are auditing - which for an agency is effectively a client roster - never passes through anyone else’s servers.
Who uses an on-page seo auditor?
The in-house SEO lead asks “did the new template break titles, canonicals or headings across our top pages?” and needs a repeatable pre-publish QA pass. The agency account manager asks “what is wrong with these thirty client URLs, in a file I can attach to a report?” and needs audit artifacts produced locally rather than uploaded to a third-party scanner. The developer asks “is this page indexable, does it ship one H1, and are the security headers in place before launch?” The content lead asks “which pages are thin, which read like a legal contract, and where did placeholder text survive to production?” All four want a dated, columnar artifact they produced themselves - not a score inside someone else’s web app.
How does a website audit bot run work, step by step?
Every command in the run is linked to its reference page. For each URL, a try_catch block wraps the goto navigation with a 60-second timeout; if navigation fails, a comment logs the failure and the run continues with the next target instead of dying. wait_for_load_state then settles the page to network-idle, and two scroll passes - to the bottom, then back to the top - trigger lazy-loaded content so late-rendered headings, images and links are counted. detect_tech_stack fingerprints the platform and stores it for the Structured_Data file. Six extract_data steps then run in order over the datasets Response_Indexability, OnPage_Elements, Content_Readability, Links_Census, Media_Performance and Structured_Data, each de-duplicating on Page_URL. A second try_catch wraps audit_accessibility, storing the AXE report so the Accessibility_AXE extraction can grade it - and if the engine cannot run, the file says so explicitly. Finally two filtered extractions produce the triage views: Critical_Issues keeps only pages with a 4xx-or-worse status, a title or H1 count other than one, duplicate descriptions or canonicals, a missing viewport, any noindex signal, more than a quarter of images missing alt text, or over 1500 DOM nodes; Healthy_Pages keeps only 2xx pages with exactly one title, one H1, at most one canonical, a title between 10 and 60 characters, and a response under 3000 ms.
What does the audit output look like?
The sample row is from Response_Indexability, the first dataset, whose columns frame every page’s verdict:
| Page_URL | Status_Code | Status_Class | Is_Success | Response_Time_ms | HTTP_Protocol | Meta_Robots | Canonical_URL | Redirect_Count |
|---|---|---|---|---|---|---|---|---|
| https://example.com/ | 200 | 2xx Success | true | 412 | h2 | index, follow | https://example.com/ | 0 |
Page_URL is the URL you submitted and the de-duplication key across all nine files, so rows from different datasets join cleanly in a spreadsheet. Status_Code and Status_Class record the HTTP response and bucket it from 1xx through 5xx, with boolean companions like Is_Success and Is_Redirect for fast filtering. Response_Time_ms is the measured response time, the lab-side timing signal in this dataset. HTTP_Protocol shows whether the page was served over h2 or h3, which matters for performance triage. Meta_Robots is the raw robots meta content, cross-checked against the X-Robots-Tag header column elsewhere in the file. Canonical_URL is the declared canonical, accompanied by verdict columns that name concrete problems - missing, multiple, relative, cross-host, or pointing elsewhere. Redirect_Count and the redirect-chain column expose hop sequences that quietly waste crawl budget. Empty values are honest empties: a page with no meta robots tag records nothing there rather than inventing a default.
What do the other eight datasets cover?
OnPage_Elements reports the title with character, word and pixel widths plus a SERP-truncation flag, the meta description with the same treatment, heading counts from H1 to H6, a full heading outline with order violations and duplicates, an hreflang audit (self-reference, x-default, relative URLs, duplicate languages), and a social-meta census scoring Open Graph and Twitter card completeness. Content_Readability carries the six readability formulas, text-to-HTML ratio, reading time, top words, stuffing verdict, placeholder-text flags, the copyright year, and the duplicate-detection fingerprints. Links_Census counts internal, external and unique links, rel values including nofollow and sponsored, missing rel-noopener on new-tab links, generic and duplicate anchor text, mailto and tel links, insecure http targets on https pages, and deep internal paths. Media_Performance audits every image for alt coverage, missing width and height as a layout-shift risk, lazy loading, srcset coverage and modern-format share, then censuses scripts and stylesheets for render-blocking weight, third-party domains, embeds, and DOM size and depth with a TTFB verdict and a 0-100 performance score. Structured_Data parses JSON-LD, flags invalid blocks with their parse errors, lists schema types, and names rich-result eligibility. Accessibility_AXE grades the AXE run and lists violations by severity with their WCAG tags.
Can it serve as a technical seo checker?
Yes - indexability is where this bot earns that label. Per page it answers whether the URL is indexable and, if not, exactly which blocker is responsible: an HTTP error, a noindex from meta robots or the X-Robots-Tag header, a meta refresh, or a non-HTML content type. It records the redirect chain hop by hop, flags host, protocol, www, trailing-slash and case changes between requested and final URL, verifies canonical resolution, checks charset declaration against the header, confirms a mobile viewport that does not block scaling, and grades seven security headers - HSTS with max-age and preload, CSP including unsafe-inline and unsafe-eval, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and COOP - into a letter grade, while flagging server-version and powered-by leaks. What it does not do is field performance: there is no CrUX or real-user data here, only lab measurements from your own machine.
How does it compare to subscription audit services?
Hosted audit products crawl your site, store the results in their cloud, and meter what you may look at by plan or by URL. This bot inverts all three: you decide the URL list, the data lands on your disk as plain CSVs, there is no per-run or per-URL charge, and the configuration file itself is yours to keep, version and re-run identically next quarter. The trade is real - you get no discovery crawl, no historical dashboard, no scheduled alerts and no pretty PDF. You get an auditable artifact and a repeatable measurement instead, which is what a diff-based workflow (this month’s file versus last month’s) actually needs.
How do you set it up on Windows, macOS and Linux?
Download the launcher for your operating system from this page. On Windows, run the executable; SmartScreen may ask for confirmation on first launch, and “More info” then “Run anyway” proceeds if you trust the published checksum. On macOS, Gatekeeper may quarantine the download; right-click and “Open”, or clear the flag with xattr -d com.apple.quarantine /path/to/OnPageSEOAuditor, then launch. On Linux, the launcher is a shell script: chmod +x ./on-page-seo-auditor then ./on-page-seo-auditor. Before the first run, paste your URL list into the urls_to_audit setting (it is required - the run will not start without it) and adjust the four threshold variables only if your SERP pixel budget or thin-content definition differs from the defaults. A run is visible-browser by design (headless is off in the configuration), so you can watch pages load; for scheduled audits, point your operating system’s scheduler - Task Scheduler, cron or launchd - at the launcher and accept that the browser window will appear.
What do I check when a run returns zero rows?
In order. If every file is empty: was urls_to_audit populated with full absolute URLs, and did navigation fail for all of them? Failed fetches are caught and written to the run log as comments, so the log tells you which URLs never loaded - a dead URL produces no row anywhere, by design. If only Critical_Issues is empty: that is the success case, no page tripped a hard check. If only Healthy_Pages is empty: your pages fail at least one strict criterion (most often title length outside 10-60 characters or a slow response over 3000 ms) - check the underlying datasets for which one. If Accessibility_AXE rows say the engine did not run: a content security policy, a blocking rule or an unreachable engine source prevented it, and the verdict column states that plainly rather than reporting a fabricated pass. The contract throughout is that failure is loud - zero rows means detection or navigation failed, never that problems were silently swallowed.
What are the bot’s limits?
It audits the URLs you submit; it does not crawl, discover or follow links, and it does not parse sitemaps. It measures lab signals, not field data - no Core Web Vitals from real users, no rankings, no backlinks, no search-console-style impressions. It blocks stylesheets and images on the wire, so it cannot judge visual rendering, paint order or how the page actually looks. It does not fix anything: every dataset is a measurement, and remediation is your job in your codebase. It has no alerting, no history and no built-in scheduler - re-run the launcher yourself and diff the CSVs. The AXE step depends on its engine being loadable in the page context, and the configuration acknowledges that with explicit error handling. And it is a snapshotter: four workers over a big list generate sustained load, so it is not a tool to point at a fragile production server during peak hours.
What is responsible on-page seo analysis?
Audit only sites you own or have explicit permission to test - pointing any scanner at someone else’s property without consent is their infrastructure decision to make, not yours. Keep lists proportionate: four concurrent workers is gentle by crawler standards but not free, and hammering a small site is indistinguishable from a bad day of traffic. Remember what the content census captures: emails and phone numbers displayed on audited pages are recorded in Content_Readability columns, and for sole traders those are personal data under GDPR, UK GDPR and equivalents - store the outputs accordingly, honour removal requests, and never turn an audit file into an outreach list. Sensitive-comment detection (stray tokens or debug notes in HTML comments) exists to help you fix leaks on your own pages, not to hunt for them on other people’s. The acceptable-use policy applies in full before your first run.
