Add filter/action hooks to override or modify existing SEO field resolvers (e.g. seo.opengraphImage)

[tuncadev]

Feature request: Add hooks to override or modify existing SEO field resolvers

Hi
First of all, thank you for the plugin - it’s a critical plugin for headless WordPress setups using Yoast.

I’d like to propose adding extension hooks (filters/actions) that allow developers to modify or override resolved SEO values (for example seo.opengraphImage) without redefining or duplicating schema fields.

---

Problem

Once a field like the following is registered:

seo {
  opengraphImage {
    sourceUrl
  }
}

there is currently no supported way to:

• modify the resolved value
• override specific fallback logic
• prevent certain sources (e.g. first content image)
• inject custom resolution rules

Because GraphQL schemas are immutable, developers are forced to:

• introduce parallel fields (seoClean, seoCustom, etc.)
• or completely bypass the plugin’s resolver logic

This leads to:

• schema duplication
• frontend complexity
• diverging SEO contracts

---

Proposed solution

Introduce filters or actions around resolver output, for example:

apply_filters(
    'wpgraphql_seo_opengraph_image',
    $resolved_value,
    $indexable,
    $post_id,
    $context
);

Or a more generic hook:

apply_filters(
    'wpgraphql_seo_resolve_field',
    $value,
    $field_name,
    $node,
    $context
);

This would allow developers to:

• modify the returned image URL
• block content-based images
• enforce featured or global images
• inject custom enterprise logic
• keep the GraphQL schema intact

---

Why this matters

• Keeps the GraphQL schema stable
• Avoids field duplication
• Enables advanced SEO control
• Aligns with WordPress’s filter-based extensibility
• Better supports headless / enterprise use cases

---

Example use case

Prevent Yoast from ever using the “first content image” fallback, while still allowing:

1. Explicit Yoast social image
2. Featured image
3. Global default image

Currently this cannot be done cleanly without duplicating fields or reimplementing resolver logic.

---

Happy to help with discussion, implementation ideas, or a PR if this aligns with the project’s direction

[ashhitch]

Thanks for opening this issue. Seems like a great idea.

If you're happy to create a PR I would happily review it and look to get it merged in.

If not I can add it to the backlog to work on.