Open Graph and Twitter Cards for WordPress

Open Graph and Twitter Cards for WordPress control much of the information social platforms can use when somebody shares a link to your website. Instead of leaving a platform to guess which title, description and image best represent the page, social metadata gives it structured information specifically designed for link previews.

A WordPress article might look perfectly correct in a browser but produce a poor social preview because the page is missing an Open Graph image, contains duplicate metadata or exposes an old cached image to the platform fetching the URL.

Open Graph and Twitter Cards do not directly control Google rankings, and they are not the same thing as schema markup or ordinary SEO metadata. Their main purpose is to describe how a webpage should be represented when another platform creates a rich preview from its URL.

For WordPress sites where search and social metadata need to be managed together, TheOneWP’s SEO Meta module provides page-level SEO and social metadata controls from the same workflow instead of requiring a separate plugin merely for social preview tags.

In this guide, we will look at how Open Graph and Twitter Card metadata works in WordPress, which tags matter most, how images and fallback values should be handled and what to check when social previews display the wrong information.

What is Open Graph?

Open Graph is a metadata protocol that allows a webpage to describe how it should be represented when shared by applications that support the protocol.

The metadata is placed inside the HTML <head> of the page.

A basic example looks like this:

<meta property="og:title" content="WordPress Security Guide">
<meta property="og:type" content="article">
<meta property="og:url" content="https://example.com/wordpress-security/">
<meta property="og:image" content="https://example.com/images/wordpress-security.jpg">
<meta property="og:description" content="Learn how to improve WordPress security with practical configuration and account protection.">

The official Open Graph protocol defines four basic properties for describing an object:

• og:title;
• og:type;
• og:image;
• og:url.

Additional properties can provide descriptions, site names, locales, image dimensions and other information.

Why does Open Graph matter for WordPress?

When somebody shares a WordPress URL on a compatible social or messaging platform, that service may fetch the page and inspect its metadata.

Without dedicated social metadata, the platform may have to infer information from:

• the HTML title;
• page text;
• images found in the content;
• other metadata;
• previously cached information about the URL.

That can produce inconsistent results.

Open Graph lets the website provide a clearer representation of the page instead of asking another application to perform archaeological research on the HTML and hope for the best.

What are Twitter Cards?

Twitter Cards are metadata used to describe rich link previews historically associated with Twitter and now with X.

The metadata retains the familiar twitter: property names.

A typical large-image card configuration might look like:

<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="WordPress Security Guide">
<meta name="twitter:description" content="Learn how to improve WordPress security with practical configuration and account protection.">
<meta name="twitter:image" content="https://example.com/images/wordpress-security.jpg">

The twitter:card value tells the platform which general card presentation the page is describing.

Two names you will commonly encounter are:

summary
summary_large_image

For editorial articles and marketing pages where the image is an important part of the preview, summary_large_image is commonly used.

Open Graph vs Twitter Cards

Open Graph and Twitter Cards solve almost the same practical problem but use different metadata names.

For example:

Open Graph:
og:title
og:description
og:image

Twitter Card:
twitter:title
twitter:description
twitter:image

A WordPress site can output both sets on the same page.

This gives platforms metadata in the format they understand and allows the website to define different values where necessary.

Can Open Graph and Twitter Cards use the same content?

Yes.

In many cases the same social title, description and image work perfectly well for both.

For example:

og:title       → WordPress Security Guide
twitter:title  → WordPress Security Guide

og:image       → /images/security-guide.jpg
twitter:image  → /images/security-guide.jpg

Separate metadata does not mean the values must always be different.

It simply gives the site the ability to control them separately when required.

Open Graph is different from the SEO title

The normal HTML title may look like this:

<title>WordPress Security Guide | Example</title>

The Open Graph title may instead be:

<meta property="og:title"
      content="The Complete WordPress Security Guide">

They can be identical, but they serve different contexts.

The HTML title is an important document title and is commonly used by search engines and browsers.

og:title is specifically metadata describing the social representation of the page.

This allows an editor to use a social title that reads naturally in a shared preview without changing the page’s normal SEO title.

Open Graph descriptions are different from meta descriptions

A normal SEO meta description uses:

<meta name="description"
      content="Learn how to configure WordPress security safely.">

An Open Graph description uses:

<meta property="og:description"
      content="A practical guide to protecting WordPress accounts, plugins and login access.">

Again, they may contain the same text.

But storing them separately gives editors the option to optimize the social preview independently from the search-oriented description.

Manage SEO and social metadata from one WordPress workflow

Search metadata and social metadata serve different purposes, but they are closely related operationally.

An editor may need to manage:

SEO title
Meta description
Canonical URL
Open Graph title
Open Graph description
Open Graph image
Twitter/X metadata

across the same post, page or custom post type.

Keeping those values inside one coherent metadata system makes it easier to understand which component owns the final HTML output.

TheOneWP’s SEO Meta module is designed around that model, combining search-oriented metadata with social metadata controls rather than making Open Graph configuration a completely separate administrative workflow.

Open Graph is not schema markup

Open Graph metadata and structured data such as JSON-LD are separate technologies.

Open Graph describes how a page can be represented as a social object.

JSON-LD structured data can describe entities and page content using vocabularies such as Schema.org.

For example, Open Graph might contain:

<meta property="og:type" content="article">

while the same page may separately contain JSON-LD describing an Article.

One does not replace the other.

For the structured-data side of WordPress SEO, see JSON-LD schema types explained.

The most important Open Graph tags

A practical WordPress implementation commonly focuses on several core values.

og:title

The social title of the page:

<meta property="og:title"
      content="Open Graph and Twitter Cards for WordPress">

og:description

A description of the page for social presentation:

<meta property="og:description"
      content="Learn how WordPress social previews use titles, descriptions and images.">

og:url

The URL representing the object:

<meta property="og:url"
      content="https://example.com/open-graph-wordpress/">

og:type

The type of object being described:

<meta property="og:type" content="article">

or for a general website page:

<meta property="og:type" content="website">

og:image

The image representing the page:

<meta property="og:image"
      content="https://example.com/images/open-graph-wordpress.jpg">

og:site_name

The website or brand name:

<meta property="og:site_name"
      content="Example">

Use absolute URLs in Open Graph metadata

Social metadata should use complete URLs rather than relying on an external crawler to resolve relative paths.

Prefer:

https://example.com/images/social-image.jpg

rather than:

/images/social-image.jpg

This is particularly important for images because the platform fetching the page needs an unambiguous location from which to retrieve the asset.

What does og:type do?

The og:type property identifies what kind of object the page represents.

Common website content may use values such as:

website
article

A homepage or general landing page can commonly be represented as a website, while editorial posts and guides can use the article type when appropriate.

The Open Graph protocol also defines additional object types for other kinds of content.

Do not select a type merely because its name sounds impressive. Metadata is more useful when it describes the actual page rather than the aspirations of whoever configured the plugin.

Article-specific Open Graph metadata

When og:type is set to article, additional article metadata can describe publishing information.

Examples include:

<meta property="article:published_time"
      content="2026-08-18T10:00:00+00:00">

<meta property="article:modified_time"
      content="2026-08-18T16:30:00+00:00">

<meta property="article:section"
      content="SEO">

This information is separate from what visitors see directly on the page, although it should remain consistent with the real content.

Why the social image matters so much

The image is often the largest visual part of a social preview.

A good social image should:

• represent the actual page;
• remain understandable at smaller display sizes;
• avoid critical content directly against the edges;
• use readable text when text is included;
• have a stable public URL;
• load without authentication;
• return the correct image content type;
• be large enough for a useful preview.

A magnificent article accompanied by a preview containing a cropped logo, half a heading and somebody’s unrelated stock photograph is still technically a social strategy. Just not an especially convincing one.

A practical social image size for WordPress

A commonly used general-purpose social sharing format is:

1200 × 630 px

This wide aspect ratio works well for many large social preview layouts and is a useful default when one image needs to serve several platforms.

The exact rendering remains under the control of the platform displaying the preview, so do not assume every service will show every pixel exactly as designed.

Keep important visual information away from extreme edges and test the final result on the platforms that actually matter to the website.

Use og:image dimensions when available

Open Graph supports structured properties that describe an image.

For example:

<meta property="og:image"
      content="https://example.com/social-image.jpg">

<meta property="og:image:width"
      content="1200">

<meta property="og:image:height"
      content="630">

<meta property="og:image:type"
      content="image/jpeg">

Providing dimensions helps receiving platforms understand the image resource more clearly.

The official Meta documentation for link share images covers Open Graph image metadata and shared previews.

Use og:image:alt when possible

The Open Graph protocol also supports:

<meta property="og:image:alt"
      content="Diagram showing Open Graph metadata in a WordPress page head">

This describes what the image contains rather than acting as another promotional caption.

If your metadata system supports it, meaningful image descriptions are preferable to leaving the field as another mysterious optional box everybody politely ignores.

Featured image vs social image in WordPress

A WordPress featured image and a social image are related concepts, but they are not necessarily the same thing.

A featured image may be designed for the website layout:

• article cards;
• archive grids;
• hero sections;
• related-content blocks.

A social image is specifically intended for external link previews.

Using the featured image as a fallback is convenient, but important pages may benefit from a dedicated social asset with the correct composition and dimensions.

Create sensible social metadata fallback rules

A practical WordPress metadata system should not require an editor to fill every social field manually before a page can produce a usable preview.

A fallback structure might look like:

Social title:
Custom social title
→ SEO title
→ WordPress post title

Social description:
Custom social description
→ meta description
→ excerpt

Social image:
Custom social image
→ featured image
→ site-wide default image

The exact fallback hierarchy depends on the implementation.

The important point is that deliberate overrides remain possible while unconfigured pages still produce coherent metadata.

This is one of the practical benefits of managing social fields together with the rest of the page metadata through TheOneWP’s SEO Meta module.

Do not create weak automatic descriptions

Fallbacks should be useful, not merely technically non-empty.

Automatically taking the first random fragment of page content can produce social descriptions containing:

• navigation text;
• shortcodes;
• builder content;
• unhelpful introductions;
• truncated markup;
• repeated headings.

If a page is commercially or editorially important, a deliberate social description is usually better than trusting whatever text happens to appear first in the rendered document.

The most useful Twitter Card tags

A practical card configuration may include:

<meta name="twitter:card"
      content="summary_large_image">

<meta name="twitter:title"
      content="Open Graph and Twitter Cards for WordPress">

<meta name="twitter:description"
      content="Learn how WordPress controls social sharing previews.">

<meta name="twitter:image"
      content="https://example.com/images/social-preview.jpg">

These properties describe the preferred card presentation and its main textual and visual content.

Do you need separate Twitter Card values?

Not always.

Many WordPress websites use the same title, description and image for both Open Graph and Twitter Card metadata.

Separate fields become useful when:

• one platform needs a shorter title;
• a different image composition works better;
• the editorial message differs by platform;
• the metadata system deliberately provides platform-specific overrides.

Do not create separate text merely because separate fields exist. Duplication for its own sake is still duplication, even when the admin panel gives it four tabs.

Open Graph URLs and canonical URLs

The Open Graph protocol uses og:url to identify the URL representing the social object.

A page may also contain the normal HTML canonical link:

<link rel="canonical"
      href="https://example.com/guide/">

and:

<meta property="og:url"
      content="https://example.com/guide/">

For a normal canonical page, keeping these values aligned avoids unnecessary ambiguity.

Tracking parameters such as:

?utm_source=social

normally do not need to become separate Open Graph objects when they merely identify the same underlying page.

Social metadata on custom post types

WordPress custom post types can use Open Graph and Twitter Card metadata just like ordinary posts and pages.

A site may have social metadata for:

• products;
• projects;
• courses;
• properties;
• documentation;
• reviews;
• case studies.

The important question is whether those post types produce public pages that are likely to be shared.

If they do, social metadata should be included in the wider SEO architecture rather than implemented only for standard posts.

For the broader indexing and metadata decisions around custom content, see WordPress custom post types and SEO.

Use one metadata owner across post types

When posts, pages and custom post types all need social metadata, consistency becomes important.

A fragmented setup might look like:

Posts
→ SEO Plugin A

Pages
→ theme metadata

Products
→ commerce addon

Projects
→ custom PHP

That can work technically, but it becomes harder to understand which component controls the final HTML on each content type.

A centralized metadata system such as TheOneWP’s SEO Meta can make the ownership of search and social metadata clearer across supported WordPress content types.

Avoid duplicate Open Graph tags

One of the most common WordPress social metadata problems is having several plugins or themes output the same tags.

For example:

<meta property="og:title"
      content="Title from SEO Plugin A">

<meta property="og:title"
      content="Title from Theme">

<meta property="og:title"
      content="Title from Plugin B">

The receiving platform now has multiple competing values.

A clean implementation should have one clear owner for each social metadata system.

Check for plugin conflicts

Open Graph tags may be generated by:

• SEO plugins;
• social sharing plugins;
• themes;
• custom PHP;
• page builders;
• marketing plugins.

When changing metadata systems, inspect the rendered source and make sure the previous solution is no longer producing stale or duplicate tags.

This is particularly important during plugin migrations, when stored social fields may also need to move to the new system.

See Migrating SEO fields between WordPress plugins.

View the rendered page source

Do not diagnose social metadata only from what the WordPress editor claims is configured.

The external platform sees the final HTML response.

Open the page source and search for:

og:
twitter:

Then verify that:

• the expected tags exist;
• there is only one intended value for each main property;
• URLs are absolute;
• the image URL loads;
• titles and descriptions contain the expected text;
• the metadata appears inside the document head;
• the page being inspected is the canonical production URL.

Why is the wrong image showing when I share a WordPress URL?

Several causes are possible.

The page may:

• contain the wrong og:image;
• contain multiple og:image tags;
• use an image the external crawler cannot access;
• reference a staging URL;
• reference an old cached image;
• lack a valid fallback image;
• be served from a cache containing older metadata.

Start with the rendered source rather than repeatedly changing random images in the WordPress Media Library and hoping a social network senses your intentions.

Social platforms cache metadata

A social platform may cache information after it first fetches a URL.

This means changing:

og:title
og:description
og:image

in WordPress does not necessarily mean every existing preview will immediately display the new information.

The live page may already be correct while an external service still has an older representation cached.

Image URLs can also be cached

Replacing the contents of an image while keeping exactly the same URL can make troubleshooting more confusing.

Different caches may continue to store the previous asset.

When an image genuinely changes, using a new file URL can make the change unambiguous:

Old:
https://example.com/social/article.jpg

New:
https://example.com/social/article-v2.jpg

For the broader mechanics behind changing cached asset URLs, see WordPress image cache-busting, explained.

Use Meta’s sharing tools when troubleshooting previews

Meta provides tools and documentation for understanding how URLs and Open Graph metadata are processed for link sharing.

Before assuming WordPress is still generating incorrect metadata, verify the live source first and then account for the possibility that the external platform has cached an earlier version.

See the official Meta sharing documentation for webmasters.

The social crawler must be able to access the page

A social preview service needs to retrieve enough of the page to read its metadata.

Problems can occur when the page or image is behind:

• HTTP authentication;
• a firewall rule;
• an IP restriction;
• bot blocking;
• a private network;
• temporary staging protection.

This is particularly relevant when testing social previews on staging.

A private staging site should remain private. Do not weaken access controls permanently just so a public crawler can generate a prettier preview for a page that is not supposed to be public yet.

Check that social images return successfully

Copy the exact URL from og:image or twitter:image and request it directly.

Confirm that the URL:

• returns the image successfully;
• does not redirect through an authentication screen;
• uses HTTPS on an HTTPS website;
• does not require a logged-in WordPress session;
• does not point to localhost or staging;
• returns an appropriate image content type.

A perfectly written og:image tag cannot rescue an image URL that external clients cannot fetch.

Be careful with dynamically generated images

Some WordPress systems generate social images dynamically.

This can work well, but the resulting URL must remain:

• stable enough to fetch;
• publicly reachable;
• fast enough to respond;
• served with a valid image response;
• independent of a logged-in browser session.

If the image endpoint requires cookies or administrator access, a social crawler will not magically borrow your browser session because it appreciates the design.

Should social images contain text?

They can, but use restraint.

Text inside an image can reinforce the topic, especially for:

• guides;
• announcements;
• case studies;
• product releases;
• editorial content.

However, social platforms may crop or resize the image.

Keep essential wording concise, readable and away from the extreme edges.

The page title and description already exist as metadata, so the image does not need to reproduce the complete introduction in microscopic typography. Humanity has endured enough tiny text.

Use a site-wide default social image carefully

A default image is useful as a final fallback when a page has no dedicated asset.

For example:

Custom social image
→ featured image
→ default brand social image

But if every page falls back to the same logo, dozens of unrelated URLs may produce nearly identical social cards.

Important editorial and commercial pages should generally have images that reflect their actual content.

Should archive pages have Open Graph metadata?

Any publicly shareable page can benefit from coherent metadata.

This can include:

• blog archives;
• custom post type archives;
• category pages;
• product categories;
• documentation indexes.

Whether an archive deserves custom social metadata depends on whether it functions as a meaningful landing page.

A useful topic hub may deserve a dedicated title, description and image. A thin mechanical archive probably does not need an editorial campaign devoted to its social card.

Should the homepage have Open Graph metadata?

Yes, a public homepage should normally provide a coherent social representation.

A typical homepage configuration might use:

og:type      → website
og:title     → brand or homepage title
og:url       → canonical homepage URL
og:image     → brand social image
og:site_name → website name

The homepage social image is a good place for a strong general brand asset rather than an image tied to one temporary article.

What happens when no social metadata exists?

The receiving platform may attempt to infer a preview from other page information.

The result may still look acceptable.

Or it may select:

• the wrong image;
• a logo from the header;
• an unrelated content image;
• an unhelpful page title;
• a poor text fragment.

Dedicated metadata reduces this ambiguity.

Do Open Graph tags improve SEO rankings?

Open Graph tags should not be treated as direct ranking controls.

Their primary purpose is social representation.

That does not make them pointless from a marketing perspective. A clearer and more attractive preview can improve how a shared URL is presented to real people.

But adding og:image is not a secret ranking incantation hidden somewhere inside the document head.

Do Twitter Cards improve SEO rankings?

The same principle applies.

Twitter Card metadata is primarily designed to describe link presentation on the relevant social platform.

Use it because accurate sharing metadata is useful, not because the presence of twitter:card magically improves the organic ranking of the page.

Open Graph and social metadata during an SEO plugin migration

When moving from one WordPress SEO plugin to another, social metadata deserves explicit attention.

The old system may store custom:

• social titles;
• social descriptions;
• social images;
• platform-specific overrides.

Disabling the old plugin before those fields are migrated can make pages fall back to generic values even when ordinary SEO titles and meta descriptions were transferred successfully.

Before switching metadata systems:

1. identify which social fields are currently populated;
2. identify where those values are stored;
3. map them to the replacement system;
4. disable duplicate output;
5. inspect the final rendered metadata;
6. test representative URLs.

See Migrating SEO fields between WordPress plugins for the broader migration process.

Using SEO Meta for Open Graph and Twitter Cards

TheOneWP’s SEO Meta module brings search and social metadata into the same WordPress workflow.

This allows important content to define page-level social information alongside its normal SEO configuration rather than relying on another unrelated plugin to own the sharing metadata.

Depending on the available values and content configuration, the social metadata workflow can cover information such as:

• Open Graph titles;
• Open Graph descriptions;
• Open Graph images;
• Twitter/X card metadata;
• social overrides;
• fallback values when dedicated social fields are not provided.

The advantage is not simply having additional fields.

The more useful benefit is having a clear metadata owner.

Instead of:

SEO title       → Plugin A
Meta description → Plugin A
Canonical URL    → Plugin A
Open Graph       → Plugin B
Twitter Cards    → Theme
Social image     → Custom code

the metadata layer can remain part of one coherent system.

Use overrides only where they add value

A centralized social metadata system does not mean editors need to create unique Open Graph and Twitter values for every page.

For many pages:

SEO title
→ suitable social title

Meta description
→ suitable social description

Featured image
→ suitable social image

may already provide a good result.

Dedicated overrides are most useful when the social presentation genuinely needs to differ.

This keeps metadata manageable instead of turning every WordPress post into a form containing twelve slightly different versions of the same sentence.

Avoid running multiple social metadata generators

If another SEO plugin is already responsible for Open Graph and Twitter Card output, running a second metadata generator can create duplicates.

Before activating or migrating to TheOneWP’s SEO Meta module:

1. inspect the current page source;
2. identify which component generates the existing tags;
3. determine whether custom social metadata needs migration;
4. choose one system to own the final output;
5. disable duplicate generation where appropriate;
6. recheck the rendered HTML.

One coherent metadata graph is easier to debug than three plugins politely disagreeing inside the same <head>.

Test social metadata before launching a WordPress site

Social previews should be part of a production launch review rather than something discovered after the first public announcement has already been shared.

Before launch, verify:

• the homepage social image;
• representative posts and pages;
• important custom post types;
• absolute production image URLs;
• production canonical and Open Graph URLs;
• the absence of staging domains;
• the absence of duplicate metadata;
• fallback behavior when no custom social image exists.

This belongs alongside the other search and metadata checks in A WordPress pre-launch SEO checklist.

Common Open Graph and Twitter Card mistakes

1. Missing og:image

The platform may choose an arbitrary image or produce a less useful preview.

2. Using a tiny social image

A technically valid image may still look poor when displayed in a large preview format.

3. Using relative image URLs

External crawlers need a clear absolute resource URL.

4. Leaving staging URLs in metadata

A production page should not advertise:

https://staging.example.com/image.jpg

as its social asset.

5. Outputting duplicate tags

Several plugins generating competing Open Graph values make preview behavior harder to predict.

6. Assuming the featured image is always the social image

The featured image may be a useful fallback, but the optimal social composition can be different.

7. Forgetting cached previews

The live HTML may already be correct while the platform still displays older cached metadata.

8. Replacing an image without changing its URL

External caches may continue serving the previous asset.

9. Treating Open Graph as schema markup

They solve different metadata problems and can coexist on the same page.

10. Treating social metadata as a direct ranking factor

The purpose is accurate and useful link presentation, not manipulating search rankings.

11. Using several plugins to own the same metadata

Choose one responsible component for Open Graph and Twitter Card output.

12. Filling every social field without a reason

Overrides are useful when they improve presentation. Otherwise sensible fallbacks are usually easier to maintain.

How to inspect Open Graph metadata manually

Open the page source and look for a block similar to:

<meta property="og:title" content="Example title">
<meta property="og:type" content="article">
<meta property="og:url" content="https://example.com/article/">
<meta property="og:description" content="Example description">
<meta property="og:image" content="https://example.com/article.jpg">

Then verify each value against what the page should actually represent.

How to inspect Twitter Card metadata manually

Search the rendered source for:

<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="Example title">
<meta name="twitter:description" content="Example description">
<meta name="twitter:image" content="https://example.com/article.jpg">

If the tags are missing, duplicated or incorrect, determine which WordPress component is responsible before changing settings randomly.

Open Graph and Twitter Card checklist

• Output an appropriate Open Graph title.
• Provide an Open Graph description.
• Use the preferred page URL in og:url.
• Choose an appropriate og:type.
• Provide a useful social image.
• Use absolute image URLs.
• Provide image dimensions when your implementation supports them.
• Add meaningful image alternative text when supported.
• Configure an appropriate Twitter Card type.
• Provide platform-specific overrides only when they are useful.
• Create sensible title, description and image fallbacks.
• Check custom post types that can be shared publicly.
• Choose one system to own social metadata.
• Avoid duplicate Open Graph and Twitter Card generators.
• Inspect the final rendered HTML rather than only the editor settings.
• Make sure image URLs are publicly fetchable.
• Check for old staging domains.
• Account for cached social previews.
• Use a new image URL when cache invalidation becomes necessary.
• Test representative URLs before a production launch.

Manage Open Graph and Twitter Cards with TheOneWP

If social metadata is currently spread across a theme, an SEO plugin, a social plugin and custom code, the first objective should be establishing one clear owner for the final output.

TheOneWP’s SEO Meta module is designed to keep Open Graph and Twitter/X-oriented metadata alongside the rest of the page’s SEO configuration.

This makes it possible to use a simple workflow:

Configure SEO metadata
→ add social overrides where useful
→ use fallbacks where overrides are unnecessary
→ render one coherent metadata set
→ inspect the final HTML
→ test the shared URL

For editors, this means fewer disconnected settings screens.

For developers, it means a clearer answer to the question:

Which component is actually responsible for the Open Graph tags on this page?

That clarity becomes particularly valuable when custom post types, migrations or multiple plugins are involved.

Final thoughts on Open Graph and Twitter Cards for WordPress

Open Graph and Twitter Cards for WordPress give websites much more control over how their URLs are represented when shared outside the site.

The core idea is simple: provide a clear title, useful description, correct URL and strong social image instead of forcing every external platform to infer those values from arbitrary page content.

Open Graph and Twitter Card metadata can share the same values when that makes sense, while dedicated overrides remain useful for pages that need a different social presentation.

Keep these tags separate conceptually from SEO titles, canonical links and JSON-LD structured data. They may all live inside the same document head, but they solve different problems.

Then make sure one system owns the output.

TheOneWP’s SEO Meta module can keep search and social metadata inside the same WordPress workflow, with dedicated social values where necessary and sensible fallbacks where they are not.

Finally, test the rendered HTML rather than trusting the settings screen. Check for duplicate tags, verify image URLs, watch for staging domains and remember that social platforms can cache previous versions of a preview even after WordPress has been updated.

When the metadata is consistent, a shared WordPress URL has a much better chance of appearing with the title, description and image you actually intended.

Which is preferable to allowing a crawler to choose the first decorative image it encounters and publicly announce that your carefully written 4,000-word guide is apparently about a footer logo.