Wp Site Audit And Onboarding

WordPress Site Audit and Onboarding Skill

Overview

Systematic onboarding guidance for inherited or unfamiliar WordPress repositories and site codebases. Core principle: before doing deep review, first classify the stack, map the moving parts, and identify the highest-risk follow-up path. This skill is meant to be the front door into the wider WordPress skill pack: plugin, theme, ACF, headless, WooCommerce, REST, migration, performance, security, CI/CD, WP-CLI, Playground, and PHPStan.

The goal is not to exhaustively review every file in one pass. The goal is to:

1. identify what kind of WordPress system this is
2. locate the architectural hotspots
3. surface obvious risk signals
4. recommend the next review skills in priority order

When to Use

Use when:

• Inheriting a new WordPress repository
• Reviewing a client site codebase for the first time
• Figuring out whether a project is plugin-driven, theme-driven, headless, WooCommerce-heavy, multisite, or builder-heavy
• Scoping risk before a migration, audit, modernization pass, or release
• Producing a quick architectural map before deeper specialist review
• User asks questions like:
  • "Audit this WordPress repo"
  • "Help me onboard to this site"
  • "What stack is this WordPress project using?"
  • "Where should I start reviewing this codebase?"
  • "What are the highest-risk areas here?"

Don't use for:

• Full security-only review (use wp-security-review)
• Full performance-only review (use wp-performance-review)
• Deep plugin architecture review after the plugin scope is already known (use wp-plugin-development)
• Deep theme review after the theme scope is already known (use wp-theme-development)
• Focused WooCommerce, ACF, REST, or headless analysis when the domain is already obvious

Audit Workflow

Follow this seven-step workflow.

1) Identify the onboarding target

Determine what you are auditing:

• entire repository
• single plugin
• single theme
• wp-content/ subtree
• monorepo app that includes WordPress as one surface
• documentation-only or CI-only configuration layer

If the target is not the full repo, note what is intentionally out of scope.

2) Detect project shape first

Classify the codebase before judging it.

Possible stack signals:

• Plugin-centric
  • main plugin headers
  • mu-plugins/
  • custom post types, taxonomies, admin pages
• Theme-centric
  • style.css, theme.json, templates/, parts/, functions.php
• Block/Gutenberg-heavy
  • block.json, src/, build/, JSX, block registrations
• WooCommerce-heavy
  • woocommerce/ templates, HPOS declarations, gateway classes, cart/checkout hooks
• Headless / WPGraphQL
  • frontend app folders, GraphQL routes, webhooks, revalidation flows, preview auth
• REST/API-heavy
  • register_rest_route(), schema callbacks, external integrations
• ACF/content-model-heavy
  • acf-json/, CPT/taxonomy registrations, field-group exports, heavy meta usage
• Multisite
  • multisite constants, network-admin logic, site/blog switching, network-wide CLI or migration code
• Bedrock / composer-managed
  • composer.json, web/, config/application.php, roots/bedrock layout
• Builder-heavy / migration-prone
  • Elementor, Divi, WPBakery, Beaver Builder, shortcode lock-in

3) Inventory key surfaces

Build a practical map of the codebase:

• bootstrap files
• active plugins/themes in-repo
• custom code directories
• build tooling (package.json, composer.json, GitHub Actions)
• deployment scripts and ops docs
• tests (phpunit, playwright, integration/E2E folders)
• docs that explain environment assumptions

Do not dump raw file listings. Summarize the structure into meaningful components.

4) Look for risk signals

Surface onboarding risks early.

Typical high-value signals:

• multiple custom plugins or sprawling theme logic without clear boundaries
• direct SQL, custom tables, or upgrade routines
• custom REST/GraphQL/auth code
• WooCommerce checkout, order, payment, or webhook integrations
• block/theme build systems that may drift from committed assets
• large ACF/meta-query dependence
• multisite assumptions
• release/deploy automation with unclear gating
• signs of builder lock-in or migration debt
• no tests, no static analysis, or no local/dev docs

5) Route to specialist skills

Recommend the next review path instead of overextending this skill.

Example follow-up routing:

• custom plugin architecture → wp-plugin-development
• custom theme / block theme → wp-theme-development
• Gutenberg blocks → wp-block-development
• WooCommerce flows → wp-woocommerce-dev
• REST routes → wp-rest-api-development
• ACF/CPT/taxonomy modeling → wp-acf-and-content-modeling
• headless / WPGraphQL → wp-headless-and-wpgraphql
• operational scripts / WP-CLI / multisite commands → wp-wpcli-and-ops
• migrations / schema changes → wp-migration-upgrade-review
• deployment pipelines → wp-ci-cd-and-release-engineering
• static analysis posture → wp-phpstan-review
• reproducible demos or bug repros → wp-playground-development
• cross-cutting security risk → wp-security-review
• cross-cutting performance risk → wp-performance-review

6) Prioritize the next actions

Output should separate:

• Immediate review priorities — where the next audit should start
• Secondary follow-ups — important, but not first
• Context notes — useful architecture observations that are not urgent problems

7) Keep severity context-aware

Use severity carefully in onboarding.

• CRITICAL: likely production risk, security/commerce/auth/migration hazard, or repo ambiguity that blocks safe work
• WARNING: important risk or missing clarity that should be reviewed soon
• INFO: structure notes, modernization opportunities, or low-risk follow-ups

This skill should not manufacture CRITICAL issues from normal architectural complexity alone.