-
Notifications
You must be signed in to change notification settings - Fork 823
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Google Rich Results ignores @context
#3455
Comments
First, please post this in the Google support forums since it's a Google specific issue. I swear they bubble up and we usually do something. Or ping me directly on Mastodon with Google SD parsing issues (@rrlevering) Second, we (Google) don't support extending schema.org vocab in this style (in the same context object). But you can have multiple contexts that are evaluated in order so you can override schema.org default behavior at least for prefix overriding. Thirdly and most importantly, we don't support a lot of context parsing, most particularly @type definitions (for value types, obviously we parse the node types). Google's systems don't pass along type information from the JSON-LD parse at all besides the native JSON types. They go in as strings, numbers, or objects based on the JSON type and then we separately post-process them with the schema.org spec to make the graph model adhere to the typing standard. This is primarily because we needed to do this anyway for microdata and deal with crappy RDFa/JSON-LD so we can't assume that things like strings/numbers are coming in correctly. I'll poke at it today a bit to see whether there are some gains I can make easily without a lot of effort. Maybe see if we can at least handle string -> @id logic in contexts. It could potentially make some things nicer without needing to specify { "@id": "foo" } node references. |
hi @rrlevering, thanks for your feedback! Can you point me to the appropriate Google support forum? We'll use "multiple contexts": should our custom context be deployed on the network (which we actually prefer), or can also be inline (which is slightly more convenient for development)?
I hear you very well. "startDate": {"@value": "2024-01-31T12:34:00+02:00", "@type": "xsd:dateTimeStamp"} Will Google parse it ok and use the
that would be useful! Please write here when/if you deploy this at Google Rich Results. |
@Kriska ^ |
I would post here: https://support.google.com/webmasters/community with a "Structured Data" tag. Generally someone will try to help you and in this case likely escalate to me via an internal bug because it's very technical. Or ping me if that's not satisfying. Sometimes that actually yields better results like documentation changes to fully document this. The only reason this is kinda fuzzy is that we host the Schema Markup Validator which is using this logic. So there is some argument for posting here, but it makes me a bit uncomfortable because it's mostly a Google focused question.
We should ignore the @type field in the your example. In @value objects we currently just use the @value field and the @language field and ignore anything else. Though honestly that would by far be the easiest one to add @type handling to (though probably less useful). |
Can you share the post URL once you have done it. I may be the guy doing the bubbling up :-) |
@VladimirAlexiev #3334 Гугловские схемы не соответствуют стандартам, хоть они и уверяют в обратном (краткая суть моей переписки с ними - "у нас все норм - ищите проблемы у себя"). |
This issue is being nudged due to inactivity. |
Hi @danbri!
(cc @gkellogg)
We've carefully crafted a context to make the JSONLD exported from our site as pleasant as possible.
It's pasted below in YAML form.
To our horror, when we tested with Google Rich Results,
https://search.google.com/test/rich-results/result/r%2Farticles?id=fbKAnENPedxeLGWKMVigPA
we see that Google completely ignores the context!
This is easiest to see from the
author
field that's interpreted as a name rather than URL:We also tried putting the context first instead of last, but the result is the same.
Maybe we need to deploy the context on a URL somewhere (rather than being embedded)?
The text was updated successfully, but these errors were encountered: