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.
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_imageFor 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:imageA 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.jpgSeparate 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.
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 a browser to resolve relative paths.
Prefer:
https://example.com/images/social-image.jpgrather than:
/images/social-image.jpgThis is particularly important for images because the external 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
articleA 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 pxThis 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">Meta recommends providing image dimensions so its crawler can understand the image size without having to infer everything from the resource itself.
The official Meta documentation for link share images covers the relationship between 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 fallback rules
A practical WordPress social metadata system often needs fallback logic.
For example:
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 imageThe exact order depends on the implementation.
What matters is that the page still produces complete metadata when an editor does not manually configure every field.
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 SEO 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 permanent 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=socialnormally 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.
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, the final HTML may contain:
<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">Now the receiving platform has multiple competing values.
The result may depend on which parser is reading the page and which occurrence it decides to use.
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 SEO systems, inspect the rendered source and make sure the previous solution is no longer producing stale or duplicate metadata.
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 is 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:imagetags; - 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:imagein 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.jpgFor the broader mechanics behind changing cached asset URLs, see WordPress image cache-busting, explained.
Use Meta’s sharing tools for Facebook previews
Meta provides tools for inspecting how a URL is understood for link sharing.
Before assuming WordPress is still broken, verify that the live page contains the correct metadata and then allow the platform to fetch the current URL again when its tools provide that capability.
The official Meta sharing documentation for webmasters explains how Open Graph markup is used when URLs are shared.
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 actually 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, the image may be cropped or displayed at different sizes.
Keep essential wording concise, large enough to remain 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 article introduction in microscopic typography. Humanity has suffered 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 imageBut 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 Facebook 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 nameThe 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 some secret ranking incantation hidden from everyone except people willing to inspect page source.
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 increases 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.
After migration, inspect representative pages and compare their rendered metadata before and after the change.
Open Graph and Twitter Cards with TheOneWP
TheOneWP SEO Meta includes social metadata controls alongside standard SEO fields.
This allows WordPress content to maintain page-level metadata for search and social presentation from the same broader SEO workflow.
Depending on the configured content type and values, social metadata can be used to control information such as:
- Open Graph titles;
- Open Graph descriptions;
- social images;
- Twitter/X-oriented title and description values;
- other supported social metadata generated by the module.
The useful part is not merely having more text boxes.
The goal is to give important pages explicit social values while still supporting sensible fallbacks when an editor does not provide a separate title, description or image.
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 a social metadata system:
- inspect the current page source;
- identify which component generates the existing tags;
- decide which system should remain responsible for them;
- disable duplicate output where appropriate;
- recheck the final rendered source.
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 when 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.jpgas 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.
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 Twitter-specific overrides only when they are useful.
- Create sensible title, description and image fallbacks.
- Check custom post types that can be shared publicly.
- 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.
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 platform-specific overrides remain available for pages that need them.
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 test the rendered output.
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.