Content intelligence reports

Create saved measurements, focused action lists, and printable client reports.

How it works

Content Intelligence Reports inspect all published public post types except attachments. The reader captures a maximum post ID and processes stable 100-item ID batches so publishing or deleting content during a run cannot shift pagination. Attached-image presence is resolved once per batch, and completed batch objects are released from the runtime cache. Posts and pages use the configurable rules; another public post type uses a 150-word fallback with no age or required-media finding. Report generation is synchronous. It is not a background job that resumes after a request timeout.

When an object-cache implementation cannot release its runtime data, both scan passes share a fallback budget of 1,000 candidate hydrations, a 20-second deadline, and a 32 MiB memory-headroom check. Exceeding that budget fails the run and releases its lease; it never completes a partial report or flushes the persistent cache backend. These checks happen at batch boundaries. They do not interrupt a database query or guarantee that an unusually large row fits in memory. A timeout or failed run is not evidence of full-site coverage.

Only one Content Intelligence Report can run for a site at a time. Generation uses an atomic, ownership-token lease that is refreshed before each content batch and before completion. The lease expires ten minutes after its last refresh, so a fatal error or timed-out request cannot strand report generation; expired takeover and release use exact-value comparisons so an older request cannot overwrite or delete a newer owner’s lease.

Each saved report records:

• the active post and page measurement rules;
• resource ID, type, title, URL, modified time, word count, age, media presence, indexability evidence, and content fingerprint;
• findings for thin content, configured freshness intervals, configured media review, potential orphans, homepage reachability, and click depth; and
• the prior completed report used for comparison.

Internal-link findings use a local graph rather than crawling the public site. Cybermaps matches links in stored published content to the report inventory and adds assigned classic-menu links plus navigation blocks referenced by active theme templates. A static front page starts at depth zero, assigned navigation targets start at one click, and breadth-first search finds the shortest stored path. The report flags:

• a potential orphan when no other stored resource or assigned navigation item points to an indexable resource;
• no homepage path when incoming links exist but the local graph cannot reach the resource from the homepage or assigned navigation; and
• three-plus clicks deep when the shortest local path is at least three clicks.

This local result is intentionally described as potential or estimated. It does not infer links from sitemaps, URL structure, page-parent relationships, rendered shortcodes, widgets, or a remote frontend. Coverage metadata records the resource, unique-link, and navigation-reference counts. Analysis stops at 10,000 resources or 100,000 unique links; incomplete stored-content or navigation traversal also marks the scan incomplete. Cybermaps suppresses all internal-link findings in those cases instead of claiming that a link is absent. Link findings enter saved-report trends only when both reports have the same complete analysis version.

Template inspection reads bounded stored overrides, active-theme files and registered template source without rendering dynamic blocks or block hooks. Stored-template reads allow ordinary WordPress query filters, so other plugins can change the results. WordPress query-style page links are matched to their canonical resources. When literal text extraction is incomplete, saved measurements expose a null full word count, omit the full content fingerprint, and record an incomplete analysis finding. Thin-content findings and comparisons are suppressed for that incomplete analysis; an unavailable measurement is never reported as a resolved thin-content issue.

Thin-content, freshness, and media findings apply only to public, search-indexable resources. Sitemap-only, AI-only, and Content Discovery Strategy exclusions do not suppress report findings. Search-noindex, password, redirect, off-site canonical, and other base indexability decisions still do. Non-indexable resources remain in the saved measurement set with their indexability decision and reasons.

The report workspace shows total resources and findings, finding categories, and added, resolved, and persisting findings since the baseline. Focused action lists isolate thin-content, freshness, media, orphan, reachability, and depth work. Exports are available as printable themed HTML, spreadsheet-safe UTF-8 CSV, and JSON, with optional agency name, URL, logo, site-name override, and a choice of Swiss, Minimal, Monochrome, Midnight, or Cyberbrand presentation.

The AI Discovery Publication Report is separate from content measurement. It records the registered fixed-path publication inventory and enablement state, then performs current public HTTP, media-type, header, and parseability validation for a client-ready HTML or JSON deliverable.

Completed reports can be selected from history. A report can be deleted only when no later report still depends on it as its comparison baseline. The admin page loads a bounded findings preview and database-computed totals; HTML and CSV exports load the complete finding inventory without hydrating unused resource rows. Structured JSON and the private read API retain the full saved resource measurements when the complete snapshot fits the shared synchronous JSON bound.

Synchronous admin exports and private report REST reads reject impractically large snapshots with HTTP 413 before hydrating them: CSV supports up to 50,000 current findings; printable HTML supports up to 25,000 current-plus-baseline findings; and full JSON—whether exported or read through REST—supports up to 25,000 combined current resources, current findings, and baseline findings. CSV response rows are emitted incrementally. These row-count ceilings reduce predictable bulk allocation; they do not guarantee that every unusually large stored row or third-party callback fits the available PHP memory. Below the limits, exports retain the saved result rather than silently truncating it.