Fixing Yoast SEO Missing on ACF Custom Post Types
The metabox is missing because of one argument in a function that has nothing to do with the SEO plugin. Ivan Sp traces a specific, recurring WordPress fault: Yoast’s SEO metabox not appearing on a custom post type built through Advanced Custom Fields. The cause almost never sits inside Yoast itself, and the real fix requires tracing a specific settings chain instead.
The Symptom
A custom post type, such as testimonials, portfolio items, or service listings, shows no Yoast metabox at all when editing an entry. Standard posts and pages carry the metabox normally. Only the custom type is affected.
Why the Fault Is Not in Yoast
The chain to trace starts at the ACF field group’s own location rules, then moves to the actual underlying post type those rules attach to. From there, three specific settings on that post type decide whether Yoast can see it at all: public, show_ui, and publicly_queryable.
A custom post type registered with any of these three set incorrectly stays invisible to Yoast’s controls, regardless of how the plugin itself is configured.
Tracing the Chain Step by Step
Start at the field group’s location rules to confirm which post type it actually targets. Then check that post type’s registration, either in a theme’s functions file or in the plugin that registered it. Confirm public and publicly_queryable are both set true, and that show_ui is not disabled.
Fixing any one of the three restores the metabox immediately, without touching Yoast’s own settings at all.
Why This Matters Beyond One Plugin
Every page type on a site, not just standard posts and pages, needs proper meta titles and descriptions in search results. A post type silently falling back to a generic default produces exactly the kind of gap a standard SEO audit can miss, since the page looks fine in the editor and only shows the fault in the actual search snippet.
Where This Fits Into a Broader Audit
This specific fault is one example of the platform-level configuration work covered under WordPress SEO, where custom post types and field plugins interact in ways a generic checklist does not anticipate.
The Arguments That Decide Visibility
- The function
- register_post_type, which is where every custom post type is declared.
- public
- The parent argument. Setting it true is what makes a type visible to SEO plugins.
- publicly_queryable
- Inherits from public. A type not queryable is not a page a search engine can reach.
- show_ui
- Controls whether an admin interface appears at all for the type.
- show_in_menu
- Controls the admin menu entry, and is inherited from show_ui.
- has_archive
- Controls whether a listing page exists for the type.
- Where ACF fits
- Advanced Custom Fields can register types, and its UI exposes the same arguments.
- Downstream effect
- A private type is also excluded from the core WordPress sitemap.
Tracing the Chain, Step by Step
I check from the platform outward rather than starting inside the plugin.
- Confirm the symptom, noting which post type is affected and whether others are fine.
- Open your SEO plugin’s content types settings and check whether the type is listed there.
- Check whether the type appears in the WordPress admin menu, which confirms show_ui.
- Open your sitemap at the site root and check whether any URL of that type appears.
- Locate the register_post_type call, in the theme, a plugin, or the ACF post type screen.
- Read the public argument, then publicly_queryable, then show_ui.
- Set public to true where the type is genuinely meant to be a public URL.
- Reload the admin screen and confirm the metabox now appears.
- Re-check the sitemap and confirm the type is now included.
- Request indexing on a sample URL, since those pages were never submitted before.
Where the Standard Troubleshooting Advice Breaks Down
Has anyone checked how that post type was actually registered?
- The usual advice
- Reinstall or reconfigure the SEO plugin, since the metabox is a plugin feature that is not appearing.
- What holds up in practice
- The plugin builds its list from post type registration. Reinstalling changes nothing, because the plugin is correctly declining to show a box for a type WordPress has declared private.
Consider a developer reinstalling Yoast, clearing caches, and disabling every other plugin in turn. The metabox stays missing throughout.
The post type was registered with public set to false. The plugin was behaving exactly as designed, and nothing inside it was ever going to change that.
Ivan Sp reads the registration arguments first. One boolean explains the symptom completely, and it is not in the plugin’s settings.
A day of plugin troubleshooting produces no fix and no understanding. The same symptom will reappear on the next custom post type somebody registers.
If the type is private, those pages are also missing from your sitemap. Google was never told they exist, and no metabox would have changed that.
Four Things Commonly Assumed About This Fault
Which of these have you tried already?
I meet these four assumptions whenever this symptom is reported.
| Commonly assumed | What actually holds |
|---|---|
| The fault is inside the SEO plugin. | The plugin reads post type registration. A type declared private is correctly excluded, and no plugin setting overrides that. |
| Advanced Custom Fields is the cause. | ACF can register the type and exposes the same arguments. The argument value is the cause, and the registration route is incidental. |
| It only affects the metabox. | A private type is also excluded from the core sitemap, from archives, and from most SEO tooling. |
| Setting show_ui to true is enough. | show_ui restores the admin screen. public and publicly_queryable are what make the type a public URL. |
| A different SEO plugin would show the box. | Rank Math and others read the same registration. Switching plugins reproduces the symptom exactly. |
Pages nobody can find a metabox for are usually pages Google has never been told about either. The metabox is the symptom, and the sitemap gap is the cost.
A Worked Example: Tracing the Chain
Consider a custom post type whose metabox never appears. The trace below is illustrative, written to show the order of elimination. No client engagement is described here.
| Check | Result | What it rules out |
|---|---|---|
| Is the type listed in the SEO plugin settings | No | A plugin configuration mistake |
| Is the type in the WordPress admin menu | Yes | The type exists and show_ui is true |
| Does the type appear in the core sitemap | No | Points at the public argument |
| Read register_post_type arguments | public set to false | The cause, confirmed |
| Set public to true and reload | Metabox appears | The fix, confirmed |
| Re-check the sitemap | Type now included | The larger problem, also fixed |
I check the sitemap before reading any code. A type absent from the sitemap and present in the admin menu narrows the cause to one argument.
Reinstalling the plugin here is replacing the lightbulb when the switch is off. The bulb was always fine.
The final row is why this matters beyond a missing box. Those pages had never been submitted to Google at all.
How This Engagement Is Scoped
What You Need Before You Start
- Time required
- About fifteen minutes once the registration code is located.
- Access needed
- WordPress admin, plus theme or plugin file access where the type is registered in code.
- Tools required
- None beyond a code editor, or the ACF post type screen.
- Skill level
- Able to read a PHP function call and identify a boolean argument.
- What can go wrong
- Making a genuinely private type public, which exposes URLs that should not be indexed.
- Expected result
- The metabox appears, and the type joins the sitemap.
- When to hire instead
- Sites with many custom types, or registration spread across several plugins.
Tools and Primary Sources
The references below document the registration and the plugin behaviour. Each opens in a new tab.
- register_post_type reference documents every argument, including the ones that decide plugin and sitemap visibility.
- WordPress core sitemaps explains which post types core includes in its generated sitemap.
- Advanced Custom Fields documentation documents its post type registration screen and the arguments it exposes.
- Yoast SEO documentation covers which content types the plugin lists and why.
Check One Post Type Yourself
I suggest a check that needs no code access at all.
- Open your SEO plugin’s content types or post types settings.
- Compare that list against the post types in your WordPress admin menu.
- Open your sitemap at the site root and check which types appear.
- Note any type present in the admin menu and absent from both other lists.
A type in the admin menu but missing from the plugin and the sitemap is registered privately. The metabox is the least of what those pages are missing.
Common Questions
Does this issue affect other SEO plugins besides Yoast?
The same underlying post type settings, public, show_ui, and publicly_queryable, affect any SEO plugin’s ability to control a custom post type, not just Yoast specifically.
Can this be fixed without editing code?
Sometimes, if the post type was registered through a plugin offering a settings interface. A post type registered directly in a theme’s code needs a code-level fix.
How do I find which post type an ACF field group targets?
Open the field group in the ACF admin screen and check its Location Rules panel, which states exactly which post type or page condition the field group attaches to.
Should every custom post type be public?
No. Types holding internal data, reusable blocks, or configuration should stay private. The fault is only a fault when a type meant to be a public page has been registered as private.
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.