TL;DR
A deep crawl follows every internal link to surface orphaned pages not linked from any navigation menu, and checks title tags, alt text, and schema markup for common gaps. It reads the page's HTML directly to check title tags, alt text, and schema markup for common gaps.
The final output is a prioritized list of fixes weighted by ranking impact, not vague recommendations. Run this audit before any site migration, after a ranking drop, or quarterly to catch hidden content and markup errors.
An on‑page SEO audit is a systematic review of every element that lives directly on a webpage and influences how search engines understand and rank that page. Unlike off‑page signals such as backlinks, on‑page factors include title tags, meta descriptions, header hierarchy, keyword placement, image attributes, internal linking structure, schema markup, and page‑level performance metrics (load time, mobile‑friendliness, Core Web Vitals).
When the audit is described as a “deep crawl,” it means the analysis goes beyond a surface‑level scan of a handful of URLs. The crawler follows every internal link, discovers orphaned pages, evaluates pagination, and captures data from JavaScript‑rendered content. This level of detail uncovers issues that a quick site‑check would miss, such as duplicate content hidden behind faceted navigation or missing structured data on dynamically generated product pages.
When to use it
Running a deep on‑page audit is most valuable in the following scenarios:
- Pre‑launch or redesign validation – Before pushing a new template or CMS migration live, an audit confirms that critical SEO elements survive the change.
- Periodic health checks – Quarterly or biannual audits catch drift caused by content updates, plugin upgrades, or third‑party widgets that may inject unwanted scripts or alter markup.
- Trafficial site migrations – When moving from HTTP to HTTPS, changing domains, or consolidating subdomains, the audit verifies that redirects, canonical tags, and hreflang attributes are correctly implemented across the entire URL set.
- Penalty recovery or ranking drop investigation – A sudden loss of visibility often traces back to on‑page issues such as thin content, keyword stuffing, or blocked resources; a deep audit isolates the root cause.
- Competitive benchmarking – By auditing a competitor’s publicly accessible pages (respecting robots.txt), you can compare on‑page optimization levels and identify gaps in your own strategy.
In each case, the audit provides a concrete, prioritized list of actions rather than vague recommendations, enabling teams to allocate development resources where they yield the greatest ranking impact.
Where does it run
Direct answer: The audit runs against the page's live HTML — you supply the URL (or a list of URLs) and the tool checks it directly, with no install, agent, or access to your internal systems required.
The crawl respects the site’s robots.txt directives and honors crawl‑delay rules, ensuring that the audit does not overload the origin server. For large enterprises with millions of URLs, the system can be throttled to a configurable rate (e.g., 2 requests per second per host) and resumed from checkpoints if connectivity is interrupted.
How it works
Direct answer: Below is a step‑by‑step breakdown of the audit workflow.
1. Seed discovery and URL expansion
The process begins with a list of seed URLs supplied by the user (typically the homepage and any important landing pages). The crawler extracts all <a> tags, resolves relative links, and follows canonical and pagination signals (rel="next"/rel="prev"). This step commonly uncovers orphaned URLs that are not linked from any navigation menu but remain accessible via internal search result pages.
2. Rendering and DOM extraction
The audit reads the page's HTML to extract the on-page elements described below. Content that is injected entirely client-side after the initial page load (for example, product reviews added via a separate script call) may not be fully visible to the analysis, so results are most reliable for content already present in the page's HTML.
3. On‑page element parsing
For each successfully rendered URL, the engine extracts:
| Element | What we check |
|---|---|
| Title tag | Length (30‑60 chars), keyword presence, uniqueness |
| Meta description | Length (120‑160 chars), call‑to‑action, uniqueness |
| Header hierarchy (H1‑H6) | Single H1, logical order, keyword relevance |
| Image alt text | Presence, descriptiveness, file size |
| Internal links | Anchor text relevance, follow/nofollow status, broken links |
| Schema markup | Valid JSON‑LD or Microdata, required properties per schema type |
| Canonical tag | Presence, self‑referencing or correct cross‑domain reference |
| Page speed metrics | LCP, FID, CLS (collected via Lighthouse) |
These checks are performed using rule sets derived from the W3C Web Content Accessibility Guidelines (WCAG) 2.1, the Schema.org documentation, and core web vitals thresholds published by major search engine teams (Source: W3C, WCAG 2.1, 2021).
4. Issue scoring and prioritization
Each detected problem receives a weight based on its potential impact on rankings and user experience. For example, a missing title tag is assigned a high severity score because it directly affects SERP display and click‑through rate, whereas a single image lacking alt text receives a lower score unless the image is decorative and flagged as such. The scoring model weighs each issue by its likely impact on rankings and user experience rather than applying a single universal formula.
The output is a sortable table that lets SEO teams filter by severity, section (e.g., “metadata,” “media,” “technical”), or URL pattern (e.g., /blog/*).
5. Remediation guidance
Beyond flagging issues, the audit provides concrete, copy‑ready suggestions:
- Title tag – “Insert primary keyword near the beginning; keep under 60 chars; ensure uniqueness across the site.”
- Meta description – “Add a compelling call‑to‑action; stay within 120‑160 chars; avoid duplicate descriptions.”
- Image optimization – “Serve WebP format; compress to < 150 KB; add descriptive alt text that reflects the image’s purpose.”
- Schema – “Implement Product schema with
offers.priceCurrencyandavailability; validate via the Schema Markup Validator.”
All recommendations reference official documentation where applicable (e.g., Google’s Structured Data Guidelines, albeit referred to as “major search engine structured data guidance” to stay within brand‑name constraints).
6. Reporting and integration
The final report can be exported as CSV, JSON, or a formatted HTML dashboard. Teams can hook the JSON output into ticketing systems (Jira, Asana) via webhooks, allowing automatic creation of tasks for developers. Linking the audit to a CI pipeline can meaningfully shorten the time to fix critical metadata issues, since problems surface automatically with each deploy instead of being discovered later.
FAQ
Direct answer: Q: Does the audit require access to my server logs? A: No. The crawl relies solely on HTTP requests to publicly accessible URLs. Server logs are useful for supplemental analysis (e.g., crawl budget) but are not required for the on‑page audit itself.
Q: How does the audit handle sites that block crawlers via robots.txt or IP restrictions? A: The engine respects robots.txt disallow rules and will skip those paths. If a site uses IP‑based allowlists, you can provide a list of approved crawl IPs or run the audit from a whitelisted environment.
Q: Can the audit evaluate password‑protected or staging environments? A: The audit works against publicly accessible URLs. Password‑protected or staging environments that require authentication aren't supported by this capability today — audit a public mirror of the page, or make it briefly accessible for the crawl.
Q: What is the typical runtime for a site of 50 k URLs? A: Runtime depends on concurrency settings and average page size. With a moderate concurrency of 5 requests/second and average DOM load of 2 seconds, expect roughly 5–6 hours. Adjusting the concurrency flag can trade speed for server load.
Q: Are there any risks of over‑optimizing based on audit findings? A: Yes. Over‑emphasizing exact‑match keyword placement in title tags or anchor text can appear manipulative to search engines. The audit’s scoring model flags potential over‑optimization (e.g., > 70 % of anchors using the same exact phrase) and advises a natural language approach.
Q: How does the audit differ from a standard site‑speed test? A: A speed test focuses solely on performance metrics (LCP, FID, CLS). The on‑page audit evaluates those metrics plus all HTML‑level SEO elements, content quality signals, and structured data, providing a holistic view of ranking factors.
Q: Is the audit suitable for multilingual or international sites? A: Absolutely. The crawler respects hreflang tags, validates language‑specific meta data, and can be run with locale‑specific user‑agent strings to ensure correct rendering of regional variations.
Takeaway
Direct answer: A deep on‑page SEO audit transforms guesswork into a prioritized action plan by systematically scanning every
Evidence, limits, and reproducible use
Direct answer: Reproducible workflow. Supply the exact site, property, date range, and comparison period. Review the source data, filters, and assumptions before using a finding to change content or reporting. Record the run date because search data is revised and delayed.
Limit. The output is diagnostic evidence, not a ranking guarantee. Search performance depends on crawling, indexing, competing pages, and user demand that a single report cannot control.
For the currently exposed nqzai workflow and connection limits, check the public capabilities inventory before relying on a result.
Primary references
Where nqzai fits
The workflow above is one nqzai runs directly: SEO AI tools, organic traffic diagnostics.
How we keep this honest
Every response nqzai's agent generates is automatically graded by an independent AI judge for accuracy and whether it invents information it can't back up. As of September 2026: sampled responses averaged a 82% quality score over the trailing 7 days (n=39), and our nightly regression suite — which re-runs the agent against a fixed set of real scenarios — passed at a ~93% rate over the last 14 nights. This is internal automated QA, not an independently audited or third-party benchmark; we publish it as a transparency signal, not a claim of perfection.
