320px Site Audit

320px Site Audit helps an administrator understand what needs attention, what

is fine, and what could not be tested. It analyses WordPress, PHP, the database,

scheduled tasks, installed components, selected source code, public pages,

technical search signals, rendered-page evidence, privacy-process answers, and

optional server evidence.

The recommended Main audit contains 46 results: the 20-result Express local

subset, ten further local WordPress checks, and 16 analyses of one bounded

same-site crawl. Separate checks cover active custom code, 1–10 components

chosen by the administrator, a controlled rendered home page, and local server

evidence through WP-CLI.

Reports lead with the observed fact and a concrete next action. Search findings

group the exact problem and show safe same-site page paths when privacy rules

allow them. Clean results stay available in a collapsed section. Method,

coverage, confidence, sources, and limitations remain available without

obscuring the answer.

The plugin analyses and explains. It does not repair, delete, optimize, update,

or change audited content, users, settings, plugins, themes, server

configuration, or databases. It writes only its own bounded run, task, result,

decision, and operation records.

Local and optional checks

• Express: 20 local WordPress and hosting-environment results.

• Main: Express plus database, filesystem, components, privacy signals, and

one confirmed, limited crawl of this site’s public pages.

• Custom code: local tokenizer and lexical signals for the active/parent

themes, MU plugins, drop-ins, and recognized active Code Snippets entries.

• Selected components: the same bounded code triage for 1–10 installed

plugins or themes explicitly selected and confirmed by the administrator.

• Rendered home page: 20 aggregate DOM, layout, form, resource,

accessibility, and data-handling signals from 1–17 confirmed anonymous GET

requests to the site’s exact origin. It does not execute page JavaScript.

• Server continuation: nine masked results from

wp 320px-audit server-scan, run by the owner over SSH without giving the

plugin SSH credentials.

• Optional browser CLI: executed-JavaScript, responsive, and automated

accessibility evidence at five fixed widths, run independently by the owner.

Static and automated findings are review signals, not proof of a vulnerability,

compatibility with every environment, search ranking, WCAG conformance, or

legal compliance. Missing or limited evidence is reported as not tested or

partial, never converted to a pass.

Privacy

The complete base report works locally without an account, license, payment,

email gate, telemetry, or automatic report transfer. Opening the plugin,

running local checks, viewing or exporting reports, cron, activation, and

uninstall do not contact 320px or another external service.

Stored evidence is bounded and masked. The plugin does not retain page HTML,

visible text, cookies, credentials, secret values, database content, or source

code. A crawl may retain a hostless, queryless page path only when its segments

do not resemble personal data, credentials, or opaque tokens. Reports and

exports should still be treated as private technical documents.

Every optional external operation is off by default. Before it runs, an

authorized administrator sees the receiver, purpose, data classes, and relevant

terms, then confirms that one operation. No scheduled task starts an external

transfer.

External services

The services below are optional and are not required for the local report.

WordPress.org checksums

Core integrity sends only the installed WordPress version and locale to

0/. Plugin integrity sends only one

administrator-selected public plugin slug and version to

json.

Ordinary network metadata is also visible to the receiver. Neither operation

sends the site URL, files, paths, component inventory, report, cookies, or

authorization. Each operation requires its own confirmation. Privacy policy:

org/about/privacy/

Wordfence vulnerability feed

The optional owner-run WP-CLI continuation has a zero-request preview. Only

after --confirm-network, it sends the owner’s bearer API key, the minimal Site

Audit user agent, and ordinary network metadata to the fixed Wordfence Scanner

Feed endpoint at

com/api/intelligence/v3/vulnerabilities/scanner. It

does not send the site URL, component inventory or versions, report, or personal

data. The complete feed is matched locally and deleted immediately. The key is

read from PX320_WORDFENCE_TOKEN and is never stored. Terms:

com/wordfence-intelligence-terms-and-conditions/

com/privacy-policy/

Request a review from 320px

An administrator may voluntarily send a review request to

ru/wp-json/wp-content-platform/v1/review-requests.

Contact-only is the default. The administrator may instead choose a short

summary, selected results, or the redacted full report. The exact payload and

byte size are previewed locally before separate consent and final confirmation.

The site URL, local identifiers, credentials, and private visual evidence are

never included. There is no retry or background submission. The response gives

an opaque request ID, deletion link, and retention date of about 90 days.

ru/terms/

ru/privacy/

ru/personal-data-consent/

Optional browser CLI dependencies and page requests

The browser companion is human-readable source included in cli/browser; PHP

and wp-admin never install or execute it. The owner independently installs its

pinned packages. With default npm settings that contacts

org/; npm terms and privacy are at

com/policies/terms and

com/policies/privacy. The Playwright installer provides a

dry run that lists its browser download URLs; documentation is at

dev/docs/browsers and Microsoft privacy terms are at

com/privacystatement.

Without --confirm-network, the companion makes no page request. A confirmed

run loads only 1–5 explicit queryless pages in a fresh sandboxed Chromium

context. The pages and their ordinary first- or third-party resources receive

normal browser/network metadata and anything page scripts place in allowed GET

request URLs or headers. Mutating HTTP methods, later document navigation,

frames, popups, saved downloads, WebSockets, WebRTC, WebTransport, and workers

are blocked within fixed request, byte, and time limits. Its ordinary JSON

contains aggregates and keyed references, not URLs, text, HTML, selectors,

field values, cookies, screenshots, or response bodies. There is no upload or

WordPress callback.