As with #7557, #7425 and #7396 we're facing more and more issues regarding structured data in AMP. Google wants to have a proper publisher.logo (warning) in 60x600px dimensions _and_ an article.image (error). Always!
But it's not only for AMP! We get the exact same errors and warnings for normal blog posts, so we need a _short term solution for LTS_, which could be like this:
article.image whenever no post image is supplied. If there's no blog cover, use a default picture (this needs to be defined, maybe something neutral, that refers to writing?)For a _long term solution_, we need image-optimisation. With that we're able to resize the publisher.logo and offer the possibility to upload a default post image, just like we do with the blog cover or logo in general settings.
Happy for other opinions here!
Google updated the guidelines and made it more clear, which requirements are for AMP specific and which once aren't: https://developers.google.com/search/docs/data-types/articles#logo-guidelines
@AileenCGN can you post an update on here with what's left to do or otherwise close this issue?
Google has the requirements specified for AMP and non-AMP pages now (see here). Regarding the two properties article.image and publisher.logo it looks like this now:
article.image: required (AMP), recommended (non-AMP)
If a post doesn't have a feature image, it'll error especially for AMP. That means, that we would always need to supply an image for AMP posts. How can we do this?
use the blog cover as a default article.image whenever no post image is supplied. If there's no blog cover, use a default picture (this needs to be defined, maybe something neutral, that refers to writing?)
Besides ^this idea, we could also crawl the content of the post for any image in there and use the first one we find.
Even though the Structured Data Testing Tool renders a warning for non-existent article image on non-AMP posts, it should be fine - according to Google - for those cases.
publisher.logo: required (AMP), ignored (non-AMP)
This changed. It used to be required for non-AMP pages as well, which takes a bit of the pain away, especially since with Ghost 1.0 our default logo is an .svg which as particularly not allowed according to Google. Again, the Structured Data Testing Tool shows a warning for both, AMP and non-AMP, as it doesn't really seem to differentiate those cases.
TL;DR: This issue might as well be renamed, as it's now only valid for AMP posts. Normal blog posts shouldn't be affected by this. I still think that this statement
For a long term solution, we need image-optimisation. With that we're able to resize the publisher.logo and offer the possibility to upload a default post image, just like we do with the blog cover or logo in general settings.
is still valid, but we might as well have it as a subtask in a possible upcoming image-optimisation issue.
Another quick fix, we could do, is to offer some additional text on the App - AMP page, where the importance of an post feature image and the requirements for the logo are either explained, or linked to (as they might change again).
Any fix for missing article.image ? It's 2018 !
A fallback to the blog cover or something sounds like an easy fix. Currently, Search Console sends warning emails about this issue. And while it may not be an issue in the search results, ignoring Search Console emails can be very dangerous. At some point, they send something critical and you have gotten used to ignoring it 馃槃
Could be a two step rocket, where you'd default to the blog cover in v1. In v2, you could implement a custom default.
often i don't add cover to posts, so
in the file './versions/1.22.3/core/server/helpers/ghost_head.js', i added this
if(!metaData.schema.hasOwnProperty('image')){
metaData.schema['image']={}
}
and it turned out to be
if (metaData.schema) {
if(!metaData.schema.hasOwnProperty('image')){
metaData.schema['image']={}
}
head.push('<script type="application/ld+json">\n' +
JSON.stringify(metaData.schema, null, ' ') +
'\n </script>\n');
}
Then passed the Google Accelerated Mobile Pages(AMP) Validation.
(Maybe it is not a good choice. But i have no idea to solve this problem.)
Hello,
Any news about "A fallback to the blog cover or something" to fix AMP warnings?
Thank you
@AileenCGN ping
AMP is currently not on the main focus but PRs for a fallback to the blog cover are very welcome!!!
I recommend that we introduce the concept of "system" image sizes, which have one or two sizes used for schema.org, and where people have linked to external images (no longer possible), we should assume they are the right size.
This would allow us to remove all of the code that handles looking up image dimensions, seeing as we are now in control of what dimensions are served, and simplify the logic extensively.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
There is activity now :smile:
Pardon me asking, but why was this closed? I'm running the latest version (v3.0.2) and I still see the following markup:
"publisher": {
"@type": "Organization",
"name": "Example",
"logo": "/path/to/logo.png"
},
...instead of:
"publisher": {
"@type": "Organization",
"name": "Example",
"logo": {
"@type": "ImageObject",
"url": "/path/to/logo.png",
},
Interestingly, I can successfully run Structured Data Testing Tool on my homepage with no issues nor warnings, but when I do the same on an article (so, a publisher within "@type": "article"), I get an error around publisher logo: A value for the url field is required.
bumpin'
Bumping again
The issue got closed because it has no traction. PRs are welcome.
Most helpful comment
I recommend that we introduce the concept of "system" image sizes, which have one or two sizes used for schema.org, and where people have linked to external images (no longer possible), we should assume they are the right size.
This would allow us to remove all of the code that handles looking up image dimensions, seeing as we are now in control of what dimensions are served, and simplify the logic extensively.