Twitter meta is not loading actual og:image url (after file is renamed)

[viktorhanacek]

• I've read and understood the contribution guidelines.
• I've searched for any related issues and avoided creating a duplicate issue.

Please give us a description of what happened

Twitter meta is not loading actual og:image url. Instead it looks like URL is saved somewhere right after uploading the image or saving the post for the first time and Yoast SEO is loading it from there.

To Reproduce

Step-by-step reproduction instructions

I'm using automatic renaming plugin which is renaming thumbnail image according to post title (yup, SEO).

I think my set-up is not easily replicable but it's not needed to replicate it to understand the issue.

1. Install File Renaming on upload Pro plugin
2. Upload photo with filename D0308942.jpg
3. Set Title to "Great Image" » renaming plugin will rename thumbnail to great-image.jpg
4. Schedule

Expected results

I'm expecting Yoast to load the actual thumbnail url from DB (great-image.jpg) whenever and whatever image is set and not loading it from some sort of its own DB field (D0308942.jpg).

Actual results

Yoast prints og:image URL for D0308942.jpg — at this time the file no longer exists because it's renamed by the renaming plugin.

I see this issue for months, maybe over year, so it's not just the latest version of Yoast SEO.

Screenshots, screen recording, code snippet

URL: https://picjumbo.com/flag-of-the-united-arab-emirates/

Technical info

Used versions

• PHP version: 7.4.28
• WordPress version: 6.4.3
• WordPress Theme: own
• Yoast SEO version: 22.1
• Relevant plugins in case of a bug: File Renaming on upload Pro

[josevarghese]

Hi @viktorhanacek

Thanks for using the Yoast SEO plugin and for creating the issue.

I tried to replicate the issue you mentioned by uploading two separate images for the Social preview and Twitter image within a post. After that, I tried to use the media rename plugin called "Phoenix Media Rename" and tried to change the media file name to another one. Then, I viewed the post page's source code and confirmed that the og:image and twitter:image meta tags were updated to the new file names.

So, it seems like something on your setup or a previous indexable created by Yoast that didn't get cleared would be showing the wrong image path on the source code. As the first step to narrow down this, we recommend you to reset the indexable after taking a full backup of your database and files. If that didn't help, we recommend you to revisit your setup, as the file rename via the plugin mentioned above and clearing the indexable helps to change the path on the source code without any issues.

[viktorhanacek]

Hi @josevarghese,

Thank you for looking into this. On the same page, I realized there is another weird behavior:

<link rel="canonical" href="https://picjumbo.com/?p=38144" class="yoast-seo-meta-tag">
<meta property="og:url" content="https://picjumbo.com/?p=38144">

But the post is published and the actual link is:

https://picjumbo.com/flag-of-the-united-arab-emirates/

Maybe it's caused by an incompatibility with the plugin I'm scheduling posts with. Once a post is published, Yoast doesn't update its data and still displays out-of-date values ​​even after publication.

I'll look into resetting the indexable and will watch if this behavior happens again.

Thank you,
VH

[josevarghese]

Hi @viktorhanacek

It would be mostly with the scheduling plugin or rewrite plugin that you are using on the website, like as mentioned over here. In this case, try to add the page URL to the canonical URL field manually and click on the Update button.

[viktorhanacek]

Hi @josevarghese,

I did reset the indexables and optimized. Then I tried to schedule a post normally in WordPress and I see the same behavior. Canonical URL is still the preview one (..com/?p=XXXX) and og:image has the old filename.

Looks like one of my indexables is on sickday :))

I have 6000 posts, 8000 tags, and had to do "SEO optimization" 3 times after resetting the indexable (got unspecified error in red box twice after like 3-5 minutes). But I have a dedicated server and a 3rd attempt was successful.

I also don't think that it's a performance issue — that the plugin no longer can update the indexable table. Because if I go to any post and hit "Update", both og:image and canonical is updated immediately.

Others with the same issue

I'm not the first with this issue, but the test below is maybe changing the trajectory of this issue.

"We don’t have quite 10,000 posts, but it’s close, and it does seem like the problem might be that optimization isn’t being completed. We’ve also had issues with the images that og:image tags not updating because of the data that’s indexed, and we’ve had to manually clear those as well – is that something that would be fixed if we completed the index via wp-cli?"
— https://wordpress.org/support/topic/disable-optimize-seo-data-option/
Things in common: thousands of posts, but there is no info if they are Scheduling their posts.

"I'm back to it not working again - after all that testing and the canonical being properly set for a scheduled post, my most recent scheduled post has the same problem - canonical is ?p=ID."
— #16266
Things in common: posts are Scheduled

"Just adding my voice to this. I have the same problem as the OP using Yoast and WP Rocket.
We have resorted to updating all of our posts to make sure the og:image is set correctly. I have also seen instances where the og:url is not using the full canonical URL as it should as well."
— #15246 (comment)
Things in common: wrong og:image + canonical, Update button will fix all data

"When it was published, the canonical was correct. Another scheduled posts had a wrong canonical."
— #15246 (comment)
Things in common: Publish button = everything ok, Schedule button = wrong "not updated" data

Another test on a 'different' website

I just did another test on my blog. It's a different site, different (almost empty) functions.php, but in the same multisite.

Test:

1. schedule a post
2. no other action than that "Schedule" click
3. wait for publication

Outcome: canonical has still the preview link.

I just wanted to know if the size of DB has any impact. But even a small table has the same problem.

Can you please check that indexables 🦸‍♂️ are catching that "URL+og:image change" when using Schedule button?

Because I have no problem when I use "Publish" button:

If you're sure that everything is working and there is no issue on your side, I'll probably disable indexables.

Thank you!

[josevarghese]

Hi @viktorhanacek

Thanks for getting back to us. I noticed that you have already spotted issue 15246, which causes this issue. I missed that "Schedule" part you mentioned while testing this case, my bad! I also asked our development team to check issue 15246 on our upcoming sprints. I hope they will be able to find out the issue in the code and will be able to fix it :)