WP Custom SEO

Modern SEO management for WordPress. Developed by Manpreet Singh.

Foundation, on-page SEO, the entity and schema graph layer, the aggregated schema API, sitemaps, breadcrumbs, social metadata, the redirect manager with its 404 monitor, the internal link graph, the bulk editor, Local SEO, the brand entity, WooCommerce, the AI assistant, the site audit, AI internal linking and FAQ generation, CSV import/export, migration from four other SEO plugins, WP-CLI commands, a configurable score model, Search Console, Analytics, email reports, AI crawler controls and the Abilities API.

Nothing here fabricates results it cannot produce. Where an external service is not connected, the feature says so and shows nothing, rather than showing zeroes or a placeholder.

Recommendations are recommendations. Nothing in this plugin is presented as a guaranteed ranking factor, and no score here represents any search engine's algorithm.

Requirements

• PHP 8.1+ (tested on 8.4)
• WordPress 6.5+

Install

Drop the folder in wp-content/plugins/ and activate. Composer is optional — without vendor/, a small PSR-4 fallback autoloader takes over.

For development:

composer install
composer test   # php tests/self-check.php
composer cs     # phpcs against WordPress standards
composer i18n   # regenerate languages/wp-custom-seo.pot (needs WP-CLI)

Lifecycle

Activation creates the tables, adds the capability to administrators and editors, and records the version. Deactivation is non-destructive: it deletes nothing, and clears every scheduled event, because an event for a hook nothing listens to any more is a row that sits in the cron option for good.

The list of those events is built from the constants the modules themselves declare rather than repeated as literal strings — it had already drifted once, and a hook that is renamed in one place and left scheduled here is invisible until someone reads the cron option.

Uninstall clears the scheduled events whatever your settings say — they are instructions to run code that is about to stop existing, not data. Everything else is removed only if you ticked Delete data on uninstall: the tables, the prefixed post, term and user meta, the prefixed options and transients, and the capability. Data belonging to other plugins is never touched, including anything this plugin imported from — a Yoast install is left exactly as it was.

Translations

Text domain wp-custom-seo, template at languages/wp-custom-seo.pot, loaded on init — WordPress warns when a domain is loaded earlier, and nothing here needs a translated string before then.

Architecture

On-page SEO

Every public post type gets a SEO panel on its edit screen: focus keyphrase, SEO title, meta description, a search-result preview, and an Advanced tab with canonical URL and noindex/nofollow. It is a classic meta box, so it renders in the block editor, the classic editor and page builders alike, with no build step.

Meta keys, all registered through register_post_meta and therefore available over the REST API with the same sanitization and capability checks:

_wpcseo_title, _wpcseo_description, _wpcseo_focus_keyword, _wpcseo_canonical, _wpcseo_noindex, _wpcseo_nofollow.

Front-end output goes through native hooks — pre_get_document_title, wp_robots, get_canonical_url and wp_head — so themes and other plugins keep their usual chance to filter it. Everything is gated behind Settings → General → Enable SEO output.

The optimization score

Analyzer scores 16 on-page checks: title length and keyphrase placement, description length and keyphrase, content length, keyphrase distribution and placement in the introduction, subheadings, heading hierarchy, images and their alt text, internal links, external references, and the URL slug.

Each check reports what was detected, why it matters and what to do about it. The score is this plugin's own measure of how completely a page follows established on-page practice. It is not Google's algorithm and does not predict rankings.

The model is editable

Because the score is a checklist and not a measurement, you get to disagree with it. Settings → Score model gives every check a weight from 0 to 5, and Weights::defaults() is the single table those weights and labels come from — they used to sit inline at each check, which made the model a fact about the code rather than a decision anyone could see.

A weight of zero excludes a check from the score without hiding its advice. The check still runs and still says what it found, marked not counted in the editor. Silencing a recommendation and disagreeing with its importance are different things, and a site whose pages are short by design should not be told forever that its content is too short.

The fields are ordinary settings, so they are registered, sanitized, saved and capability-checked by the same code as everything else. A check added through wpcseo_analysis_checks that is not in the model is worth 1 rather than nothing, so a third-party check is never silently ignored; add it to wpcseo_score_model to give it a weight and a settings field of its own.

Entities and the schema graph

The plugin describes a site as entities with stable identifiers, and emits one connected @graph per page rather than isolated JSON-LD blocks. An entity is stated once and referenced by @id everywhere else, so a consumer can resolve author, publisher and page into a single description.

Organization ──publisher── WebSite
     │                        │
     │                     isPartOf
     │                        │
     └──publisher──── Article ──author──► Person
                         │
                    mainEntityOfPage
                         ▼
                      WebPage ──primaryImageOfPage──► ImageObject

Identifiers are derived from the site URL — …/#/schema/organization, …/#/schema/person/12, <permalink>#webpage, <permalink>#article — so they stay stable across requests without a table to keep in sync.

Nothing is invented. Every builder omits a property it cannot establish from real data, and returns nothing at all when the entity does not exist. The organization trust properties (publishingPrinciples, correctionsPolicy, ownershipFundingInfo, actionableFeedbackPolicy, diversityPolicy) are emitted only when you supply a URL for a page that genuinely exists. Invalid URLs in any list are discarded rather than published.

Validation

SEO → Schema validates the graph for a chosen post or the front page: unique @ids, resolvable references, absolute URLs, present @type, and the properties each type needs to be usable. Errors, warnings and notices are distinguished — and a graph with errors is withheld from the front end rather than published, because wrong structured data is worse than none.

The screen also lists other active structured-data emitters (Yoast, Rank Math, AIOSEO, SEOPress, Schema Pro, WooCommerce). Nothing is ever disabled automatically; you choose which source to turn off.

Per-post schema type lives on the editor's Schema tab. HowTo is deliberately absent: it requires the visible page to actually contain that content, and will be offered once the module can verify it.

FAQPage is derived, never chosen

FAQPage is not on the type list either, for the same reason — but it does not need to be, because the plugin can verify it. Content is read for a real question-and-answer structure: a heading ending in a question mark followed by its answer, or a <details>/<summary> disclosure block. Find two or more and the page node gains FAQPage alongside whatever it already was, carrying the questions as mainEntity. Find fewer and nothing is emitted.

A heading that merely starts with an interrogative word ("How we work") is a statement, not a question, so the question mark is required rather than inferred. Generating FAQ text with the AI assistant does not switch this on: the text has to be on the page first.