automattic/jetpack-seo

Jetpack SEO — the visibility command center for WordPress sites in the agentic web.

v0.1.0 2026-06-08 15:30 UTC

Requires

• php: >=7.2
• automattic/jetpack-admin-ui: ^0.9.1
• automattic/jetpack-status: ^6.1.7
• automattic/jetpack-wp-build-polyfills: ^0.1.12

Requires (Dev)

• automattic/jetpack-changelogger: ^6.0.16
• automattic/jetpack-test-environment: @dev
• automattic/phpunit-select-config: ^1.0.8
• yoast/phpunit-polyfills: ^4.0.0

Suggests

• automattic/jetpack-autoloader: Allow for better interoperability with other plugins that use this package.

GPL-2.0-or-later

README

The visibility command center for WordPress sites in the agentic web — a unified wp-admin screen that consolidates SEO, sitemaps, AI discoverability, and site verification settings across all site types (self-hosted, Atomic/WoW, Simple).

This package is built up across a stacked series of PRs (see #48154 for the split plan). It currently provides, on a wp-admin page registered at admin.php?page=jetpack-seo (gated on the seo-tools module being active):

• Overview — a dashboard with Site visibility and Site verification cards, each deep-linking into the matching Settings section.
• Settings — a tab to configure search-engine indexing, the XML sitemap, post title structure, the front-page description, and site verification codes.

The Per-post SEO (Content) and AI (llms.txt / AI crawlers) tabs land in follow-up PRs.

Architecture

Built as a @wordpress/build (wp-build) dashboard, the pattern shared by recently-shipped Jetpack admin pages (Podcast, Scan, Forms, Newsletter):

• PHP: Automattic\Jetpack\SEO\Initializer registers the admin menu via Admin_Menu::add_menu(), loads wp-build's generated bundle (build/build.php + WP_Build_Polyfills::register()), and bootstraps the app's initial state. Because the user-facing slug (jetpack-seo) differs from wp-build's page slug (jetpack-seo-dashboard), the screen id is aliased on current_screen so wp-build's auto-generated enqueue callback fires.
• React: an ES-module bundle. Routing uses @wordpress/route; the Overview and Settings tabs are ?tab=-driven panels. _inc/app.tsx wraps them in the AdminPage chrome from @automattic/jetpack-components. UI uses @wordpress/components, @wordpress/ui, and @wordpress/icons.
• Data: read-only initial state for both tabs is bootstrapped server-side onto window.JetpackScriptData.seo.{overview,settings} via the jetpack_admin_js_script_data filter (Initializer::inject_script_data()) and read synchronously on the client through @automattic/jetpack-script-data. wp-build pages load as ES modules, so wp_localize_script can't bootstrap them — the script-data layer is the supported channel. The package registers no REST controller of its own: Settings writes reuse the existing /jetpack/v4/settings endpoint (and core /wp/v2/settings for the blog_public search-engine-visibility option).

Development

# Build once (from the repo root)
jetpack build packages/seo

# Watch mode
pnpm --filter='@automattic/jetpack-seo' run watch

# Typecheck
pnpm --filter='@automattic/jetpack-seo' run typecheck

# Tests
pnpm --filter='@automattic/jetpack-seo' run test

The built JS/CSS lives in build/ and is included in the vendored Jetpack plugin distribution via .gitattributes (/build/** production-include).