WordPress SEO
A custom post type registered with one wrong argument becomes invisible to every SEO plugin on the site. Ivan Sp implements SEO directly on WordPress, using the platform’s open database and template access. WordPress is the platform every programmatic and schema automation system on this site targets first. Custom code can reach the database and custom post types directly.
What Direct Access Actually Enables
Custom PHP can write directly into the WordPress database and into custom post types. This level of access makes programmatic content systems, bulk schema generation, and template-level internal linking logic possible, without fighting the platform. A database-driven build covered under programmatic SEO reaches its full depth only where that access exists.
Other platforms in this comparison restrict template and database access by design. They trade flexibility for a simpler hosted experience. That tradeoff is not a flaw, and it means implementation work looks different on each platform, covered on the other pages in this section.
Where Custom Post Types Go Invisible to SEO Plugins
A custom post type built through a field plugin, such as one used for testimonials or portfolio items, can stay invisible to a standard SEO plugin’s title controls. A specific chain has to align first: the field group’s location rules, and the underlying post type’s public and queryable settings.
Left unfixed, every page of that content type silently falls back to a generic default title in search results. The fault is invisible in the page editor, and only shows up once someone checks the live search snippet.
Plugin Configuration Beyond the Defaults
Default SEO plugin settings are generic by necessity. Most sites need deliberate configuration beyond them: title and meta templates set per content type, breadcrumbs enabled, sitemap settings reviewed, and non-public content types hidden from search results.
Left at their defaults, these settings commonly let thin, auto-generated archive pages get indexed alongside genuine content. That dilutes the site’s overall quality signal for no benefit.
What WordPress Does Not Solve on Its Own
Open access is a capability, not a guarantee. A WordPress site with no canonical strategy, no content plan, and no technical audit carries the same faults as any other platform, covered under technical SEO and content strategy. Access simply means those fixes can go deeper once identified.
Where the Standard WordPress Advice Breaks Down
- The usual advice
- Install an SEO plugin, work through until every light turns green, and the site is optimised.
- What holds up in practice
- The lights only cover what the plugin can see. Content held in custom fields and post types registered without the right arguments are invisible to the plugin, and it will report green anyway.
Imagine a property site with 400 listings built as a custom post type, every field held in Advanced Custom Fields. The SEO plugin shows a clean dashboard.
The plugin never listed those 400 pages, because the post type was registered with public set to false. Four hundred pages had no title tag rule, no description, and no analysis.
I check the post type registration before trusting any plugin report. A green dashboard describes the pages the plugin knows about.
Four hundred invisible pages is not a plugin bug. The gap reports as success, and few problems are harder to notice than that.
Four Things Commonly Assumed About WordPress SEO
How many of your pages does your SEO plugin actually know about?
I meet these four assumptions whenever a plugin dashboard is treated as an audit.
| Commonly assumed | What actually holds |
|---|---|
| A green SEO plugin dashboard means the site is optimised. | The lights cover only what the plugin can see. Content in custom fields and privately registered post types are invisible to it. |
| WordPress handles sitemaps, so nothing needs checking. | Core generates sitemaps for public post types only. A type registered without the right arguments never appears. |
| Two SEO plugins provide more coverage. | Two plugins commonly inject conflicting structured data and duplicate meta tags, which is worse than either alone. |
| Page builder content is the same as post content. | Some builders store content outside the main post field, where plugin analysis and some export tools cannot read it. |
| Plugin defaults are safe. | Defaults commonly index tag and author archives, which produces thin duplicate pages on a content-heavy site. |
A custom post type registered with one wrong argument makes hundreds of pages invisible to your plugin, your sitemap, and Google at the same time. The dashboard will still show green.
WordPress Reference Points
- Core sitemaps
- WordPress has generated XML sitemaps in core since version 5.5.
- Custom post types
- Registered with register_post_type, which takes the arguments that decide visibility.
- The argument that matters
- public set to true, which is what makes a type appear to SEO plugins.
- Related arguments
- publicly_queryable, show_ui, and has_archive, which control different surfaces.
- Advanced Custom Fields
- A field framework whose content sits outside the main post content field.
- Why that matters
- An SEO plugin analysing post content will not see text held only in custom fields.
- Permalink structure
- Set globally, and overridable per post type through the rewrite argument.
- Common plugins
- Yoast SEO and Rank Math, both of which read post type registration to build their lists.
A Worked Example: Why a Post Type Disappears
Consider a custom post type that never appears in the SEO plugin’s list. The comparison below is illustrative, written to show which argument does what. No client engagement is described here.
| Argument | Set incorrectly | Set correctly |
|---|---|---|
| public | false | true |
| publicly_queryable | Inherited as false | true |
| show_ui | false, so no admin screen appears | true |
| has_archive | false, so no listing page exists | true where an archive is wanted |
| Visible to the SEO plugin | No | Yes |
| Included in the core sitemap | No | Yes |
Ivan Sp starts at the registration rather than at the plugin settings. One argument decides whether 400 pages exist as far as every other tool is concerned.
A post type registered privately is a filing cabinet in a locked room. The documents are real, correctly filed, and nobody with a key ever walks past.
The sitemap row matters as much as the plugin row. A type excluded from registration is excluded from the core sitemap too, so Google never receives the URLs.
How a WordPress Audit Runs
I audit the platform layer before the plugin layer, since the plugin only reports what it can reach.
- List every registered post type, and record the public and publicly_queryable values for each.
- Compare that list against the post types the SEO plugin displays in its own settings.
- Check whether page content lives in the main editor or in custom fields the plugin cannot read.
- Open the core sitemap and confirm every intended post type appears in it.
- Review the permalink structure, and confirm no post type carries an unintended prefix.
- Audit the plugin configuration beyond defaults, including archive noindex rules and taxonomy settings.
- Check for two plugins injecting structured data, which produces conflicting markup.
- Crawl the site and compare the crawled URL set against the sitemap and the admin post counts.
- Test one template change on staging before applying it across the theme.
- Re-crawl after deployment, and confirm the previously invisible pages now carry metadata.
How This Engagement Is Scoped
I scope WordPress work by the number of custom post types and templates rather than by page count.
- What arrives
- A post type audit, a plugin configuration review, and the exact code or setting change per fault.
- Typical duration
- Two to three weeks for a site with several custom post types.
- What the client supplies
- Admin access, theme or child theme edit access, and a staging environment where possible.
- Included
- Registration audit, plugin review, sitemap verification, and a verification crawl.
- Not included
- Plugin development, theme rebuilding, and paid licence costs.
- What changes the estimate
- Heavily customised themes, many custom post types, or a page builder holding content.
- How it is quoted
- After a short scoping call, once the post types are listed.
Tools and Primary Sources
The references below are the primary documentation. Each opens in a new tab.
- register_post_type reference documents every argument, including the ones that decide plugin visibility.
- WordPress core sitemaps explains which content core includes in its generated sitemap.
- Advanced Custom Fields documentation documents where field content is stored and how it is rendered.
- Yoast SEO documentation covers the plugin’s content analysis and which post types it lists.
- Screaming Frog SEO Spider crawls the rendered site, which is how invisible post types are found from outside.
Check One Post Type Yourself
I suggest a check that takes about five minutes and needs no code.
- Open your SEO plugin’s settings, and find its content types or post types list.
- Compare that list against the post types shown in your WordPress admin menu.
- Open your sitemap at the site root and check whether each type appears.
- Note any type present in the admin menu and absent from both lists.
A post type in the admin menu but missing from the plugin and the sitemap is registered privately. Those pages have no metadata rules and Google is never told they exist.
Common Questions
Does WordPress rank better than other platforms by default?
No. Platform choice affects what is technically possible to implement, not a default ranking advantage. A poorly optimized WordPress site loses to a well-optimized site on any platform.
Is a page builder plugin a problem for SEO?
Some page builders generate bloated markup that slows load time and complicates heading structure. Effects vary by builder, and an audit checks the actual rendered output rather than assuming a problem from the plugin name alone.
Can WordPress support a large, programmatically generated site?
Yes, and it is the platform of choice for that work, since custom code can write into the database directly. Database performance and hosting still need to scale with page count.
Why does Yoast not show a custom post type?
The plugin builds its list from post type registration. A type registered with public set to false does not appear, and neither does one with publicly_queryable left false. The fix belongs in the registration code rather than in the plugin settings.
Discuss This Work
The first call is a free 30-minute consultation with no pitch attached. You receive an honest assessment of where the site stands and what can realistically be built.