What's a `<script type='application/ld+json'>{jsonObj}</script>` in a `head` section do? - seo

I got this link but didn't understand well. Saw:
<script type="application/ld+json">
{
"#context": "http://schema.org",
"#type": "WebSite",
"url": "http://website.com",
"name": "wbs",
"description": "Web Studio"
}
</script>
in a source code.
How a code snippet like above in my website header help me or my site?

In your example, the script element is used as data block, which contains JSON-LD (type="application/ld+json").
JSON-LD is a RDF serialization. It allows you to publish Linked Data (or structured data) using JSON. In your example, the vocabulary Schema.org is used ("#context": "http://schema.org").
This structured data can be used by any interested consumer. Prominent consumers are the search engines Bing, Google, Yahoo, and Yandex, which support structured data that uses the vocabulary Schema.org. One use case they have is displaying more details in their result snippets.
Your example probably doesn’t lead to such an enhanced snippet. You have to check the search engine’s documentation if you want to know what features they offer and which structured data you have to provide for these. For example, Google uses the WebSite type (that’s used in your example) for their Sitelinks Search Box, but you would have to add a potentialAction in addition (for the search function).

It gives Google and other crawlers structured data about a website. This is used for rich snippets and knowledge graph panels among others. Have a look at this site for more information: https://developers.google.com/search/docs/guides/intro-structured-data

That's one way to include structured data in your site which helps any kind of users/crawlers use the information on the site in an efficient way. The most popular example is Google news cards:
This kind of card data are actually coming from structured data.
Other ways to include structured data is through Microdata
And the time of asking this question, I have no idea about these. Now I worked on structured data for some publishers.

The snippet you got is a script containing JSON-LD data format, a method of encoding Linked Data using JSON. Schema.org vocabulary is used to mark up web contents so that they can be understood by majors search engines (Google, Microsoft, Yandex and Yahoo!). Search engines use this information to display to display relevant .contents to users. For instance, you a website with a well-known term as it’s brand name e.g. Coder. Search engines will interpret it as someone who writes code for softwares. To help search engines interpret this better, you need to provide the data using Schema.org vocabulary.
e.g.
<script type="application/ld+json">
{
"#context": "http://schema.org",
"#type": "WebSite",
"url": "https://coder.com",
"name": “Coder”,
"description": “Platform to learn code”
}
</script>

<script type="application/ld+json">
{
"#context": "http://schema.org",
"#type": "WebSite",
"url": "http://website.com",
"name": "wbs",
"description": "Web Studio"
}
</script>
The snippet above is a JSON-LD based Structured Data Island (or Block) embedded in HTML that provides data to User Agents (Software Apps) for additional processing. This data can take the form of Metadata that informs said User Agents about the nature of the host document.
For instance, you can inform a User Agent such as Google's Crawler about the identity of a person associated with a document by embedding the following structured data island:
## JSON-LD Start ##
{
"#context": "https://schema.org",
"#type": "Person",
"#id": "https://stackexchange.com/users/74272/kingsley-uyi-idehen#me",
"mainEntityOfPage": "https://stackexchange.com/users/74272/kingsley-uyi-idehen",
"sameAs": "https://stackexchange.com/users/74272/kingsley-uyi-idehen",
"name": "Kingsley Uyi Idehen",
"description": "#kidehen Identified at Web, relatively"
}
## JSON-LD End ##
This is possible because the semantics that underly the schema:sameAs property deem it to be uniquely identifying.
You can also add a browser extension (e.g., our Structured Data Sniffer) to your existing browser(s) that understands the power of structured data islands deployed using , producing what's depicted in the attached screenshot.

I wrote this JavaScript code for users to write your brand name on Google.
The search form will be displayed to users.
Users only need to type in your brand name to display this search and it is most commonly used on the homepage.
To use this code copy the JavaScript and paste it at the bottom of the last line of the main content, and don't worry the JavaScript code will not be displayed to users and will only appear in Google results.
<script type="application/Id+json"> {
"#context": "schema.org",
"#type": "WebSite", "url": "coolernew.com", "potentialAction": {
"#type": "SearchAction", "target": "query.example.com/search?q={search_term_string}", "query-input": "required name=search_term_string"
}
} </script>

Related

JSON-LD Schema.org event info not being pulled into Google

I have a handful of WordPress websites that use The Events Calendar for displaying events that are open to the public.
I notice if I type a cities name and then the word event, that our website is not being pulled in to the special section that appear. Google uses its Knowledge Graph. I was looking through the source code and noticed that our sites uses JSON-LD, generated from the information used for the event, one of the methods Google talks about using, but don’t understand why our site information isn’t being shown.
These sites have been up a year and get 3k visits a month so they're being indexed fairly regularly.
I was looking through the event properties JSON-LD, and I noticed the entire event address (street, city, state zip) gets put inside the name property of the Place or Postal array (Heres a screenshot of my sites schema). When I look up other events that are pulled into Google, they list the those attributes in the address properties (Screenshot of other site’s schema).
I think because the address is put into the name property instead of the address property, that Google might not be showing the events. Has anybody else seen this happen with their sites? Or is something else wrong with the sites we set up?
Right now your events are marked up using the Google example, but I believe this is wrong:
https://developers.google.com/structured-data/rich-snippets/events
"location" : {
"#type" : "Place",
"sameAs" : "http://www.hi-dive.com",
"name" : "The Hi-Dive",
"address" : "7 S. Broadway, Denver, CO 80209"
}
2019 edit: The markup and URL above have since changed and match what is expected from the testing tool.
In order for your sites structured data to match that other event you have a screen shot of, you will need to adjust your JSON-LD to the way it's presented on schema.org, which uses PostalAddress and narrows down a little bit more:
https://schema.org/location (and https://schema.org/PostalAddress) - Click the JSON-LD example tabs
"location": {
"#type": "Place",
"name": "Withworth Institute",
"address": {
"#type": "PostalAddress",
"addressLocality": "Seattle",
"addressRegion": "WA",
"postalCode": "98052",
"streetAddress": "20341 Whitworth Institute 405 N. Whitworth"
},
"url": "wells-fargo-center.html"
}
I can't say for certain if this is the primary reason for your issue but I do think you should follow the schema.org approach either way. Even the Structured Data Tool per your screenshots seems to indicate that it's looking for postalAddress even though Google doesn't use that in the example.. perhaps that article is outdated.
I can confirm that a migration to JSON-LD from inline RDFa style schema, which validates 100% using their new rich snippet validator tool no longer shows Review stars in search results. They've also taken away the ability to see stars validate using old style RDFa schema validation.
This could be an issue with the search team not talking to the developers responsible for the structured data and schema tools, rolling out disjointed feature upgrades. Their recommended use of JSON-LD will likely have a negative impact on display in search in the near term if you'd like to see additional meta data populate in search results pages.
If meta data in search results is a firm requirement you could roll off your JSON-LD module and use a module with the older RDFa or microdata implementation inline in your HTML. Hopefully this will be remedied soon.

Enabling Google Sitelinks Search Box?

I'm trying to enable Google Sitelinks Search Box.
It's something which allows you to display directly a "search textbox" in Google : https://developers.google.com/structured-data/slsb-overview
I've added it to the website the 27 July, using the JSON-LD syntax. According to Google, the currently cached version of website is the one of the 6 August (so a long time after deployment), but the search textbox has never appeared in Google.
<script type="application/ld+json">
{
"#context": "http://schema.org",
"#type": "WebSite",
"url": "https://fr.blabla.com/",
"potentialAction":
{
"#type": "SearchAction",
"target": "https://fr.blabla.com/acheter/{search_term_string}?page=1",
"query-input": "required name=search_term_string"
}
}
</script>
Sorry, I can't disclose the real URL. On the screenshot, the subdomain and the end of the URL are the real ones, the website is in HTTPS.
The "search engine" URL works fine if I call it directly.
The code is located in the head HTML segment of my page (it's not easy to test to move it, the website is a huge e-commerce platform and I can't test anything as I would).
The Google test tool (https://developers.google.com/structured-data/testing-tool/) seems to validate my code: http://i.stack.imgur.com/PyYpL.jpg
I found another website (type "cdiscount" in Google) which use it exactly like me and it looks like to work for them. The only differences I notice is they are not in HTTPS, their subdomain is www and their <script> tag is somewhere in the body.
There's two thing to consider here...
It can take Google a while to implement your code. I've seen it take a couple of months.
Adding sitelinks in the SERPs is at Google's discretion so having the code in your site is not a guarantee they will show sitelinks for the site.
So I'm afraid it's now a waiting game.
Good luck.
Actually it only takes a few days at the most after you use Fetch as Google to have the site re-crawled.
The documentation states that it is at their discretion and may depend on how busy your site is, but mine has been running under a year and isn't busy and they work. (I was surprised since I could not confirm this elsewhere).
A common mistake is not to realize how to check sitelinks, you need to search for the full website name eg blabla.com or blabla - using site:blabla.com won't show the site links.
If you want to see the Search text box as well make sure you only add the code to the home page of your site.

RESTful way of referencing other resources in the request body

Let's assume that I have a resource called group with the following representation:
{
"id": 1,
"name": "Superheroes"
"_links": {
"self": {
"href": "http://my.api.com/groups/1"
}
}
}
Now let's say I want to create a new person instance by POSTing to /persons/1. Which of the following should I use for the request body:
Using ID
{
"name": "Batman",
"groupId": 1
}
Using link
{
"name": "Batman",
"group": "http://my.api.com/groups/1"
}
With the first method I access the id directly either to look up the related resource or eventually store the id in the database, when I persist the person instance. But with the other method, I either have to extract the id from the URI or, follow the link to load the related resource, and then find out its id. I really don't want to store the URI in the database.
With the latter option, seeing that the server controls the structure of the URI, is it fine for me to parse the id out of the link? Following the link back to the server itself seems odd, seeing that at this point we already have access to the information directly (we just need the id).
So to sum up, which of these options is best?
Use the id directly.
Use the link, but parse out the id.
Use the link, but access the link to get the resource instance, and then get the id.
TL;DR: Use simple ids.
More detailed explanation:
A straightforward approach is to create a person by POSTing to /groups/1/persons with a payload {"name": "Batman"}.
However, while such approach works for simple cases, the situation gets complicated if there are 2 resources that need to be referenced. Let's assume that a person also needs to belong to exactly one company:
GET /persons/1
{
"name": "Batman",
"group": 1, // Superheros, available at /groups/1
"company": 5 // Wayne Enterprises, available at /companies/5
}
Since there is no relationship between companies and groups, it is not semantically correct to create a person via POSTing to /groups/1/companies/5/persons or to /companies/5/groups/1/persons.
So let's assume you want to create a person with a request looking like this:
POST /persons
{
"name": "Batman"
"group": ???, // <--- What to put here?
"company": ??? // <--- What to put here?
}
Which brings us to the answer to your question:
Ease of use. Your API should be primarily designed for the ease of use. This is especially true, if you design a public API. Therefore, Option 2 (Use the link, but parse out the id) is out, since it imposes additional work for clients of your API.
Constructing search queries. If you want to be able to query persons which belong to the company 10 and the group 42, simple ids lead to more readable and less error-prone urls. Which of the following do you consider more readable?
URL with a simple id:
GET /groups/42?company=10
or URL with a url-encoded link:
GET /groups/42?company=http%3A%2F%2Fmy.api.com%2Fcompanies%2F10
I wouldn't underestimate the point of readability. How many times do you need to debug your API in various curls, logs, postmans, etc.
Development Links need to be parsed in the backend, while simple ids can be used directly. It's not about performance, but rather about additional work/tests you have to put in.
Endpoint maintenance. Imagine that your API endpoint evolves. You decide one day to switch to https or to include versioning in the url. This might break API clients, if they for some reason rely on structure of the links. Also, you might want to checkout if link parsing on your backend is done properly.
Argumentum ab auctoritate I know this is not a proper argument, but if you checkout APIs of large players, e.g. Twitter, Github or Stripe, they all use simple ids.
HATEOAS. One common argument in favour of links is that it is aligned with HATEOAS. However, as far as I know, this relates to additional links in API responses rather than using links in payloads of POST requests.
All in all, I would go for simple ids, since I haven't yet heard a compelling argument favouring links, which would beat the aforementioned.
You are missing two important things here.
You need a standard way to describe forms in the response, in this case your POST form.
The information about the group ids / uris, or how to get them has to be described in the form in a standard way.
For example a HTML FORM with a SELECT INPUT would be RESTful. The closest thing we got in json to do the same is json-ld and hydra. But if you are obsessed with hal, then use hyperagent forms or something like that. It will never be a standard, but if compatibility is not an issue, then it is good enough.
To answer your question, you should use the id, because the server knows how to interpret it. The client needs the resource identifiers, the server needs it only in the uri part of the request, not in the body.
From my experience, it is always best to go with the simplest solution for making requests.
The process of generating a new url and parsing it seems excessive to get a resource, whereas sending the id of the item you want seems much simpler.
Thus, I would send a request in the form:
{
"name": "Batman",
"group": 1
}

Json-LD: Linking documents using Json-LD

I am creating a desktop application using node-webkit.
The purpose of creating the application is to add documents and that anyone can comment on the document. The document will be split into paragraphs and people can comment on the paragraphs. Each of the paragraphs will be considered as different sections. I would like to link each section (or paragraph) with the comments using JSON-LD.
I am new to JSON-LD and I would like to know how it can be used.
In a document (an HTML document, anyway), sections (or any element) can be identified using the #id attribute, which typically becomes a fragment identifier for the document. For instance, http://www.w3.org/TR/json-ld/#abstract is a URL with the "abstract" fragment identifier, if you look at the html source, you'll see the following:
<section id="abstract" class="introductory" property="dcterms:abstract" datatype="" typeof="bibo:Chapter" resource="#abstract" rel="bibo:chapter"><h2 aria-level="1" role="heading" id="h2_abstract">Abstract</h2>
<p>JSON is a useful data serialization and messaging format.
This specification defines JSON-LD, a JSON-based format to serialize
Linked Data. The syntax is designed to easily integrate into deployed
systems that already use JSON, and provides a smooth upgrade path from
JSON to JSON-LD.
It is primarily intended to be a way to use Linked Data in Web-based
programming environments, to build interoperable Web services, and to
store Linked Data in JSON-based storage engines.</p>
</section>
(note that some of this is automatically generated, so there is other non-relevant boiler plate as well).
This provides you one mechanism of describing the structure of a document using JSON-LD:
{
"#id": "http://www.w3.org/TR/json-ld",
"#type": "bibo:Document",
"bibo:chapter": [{
"#id": "#abstract"
}, {
"#id": "#sotd"
}, {
"#id": "#references"
}],
}
Note, in this case, the JSON-LD is defined to have the same URI (URL) of the HTML document, so the "#abstract" really expands to http://www.w3.org/TR/json-ld#abstract, this providing you a way to reference that section, and an identifier for the section. Much more is possible.
In fact, many W3C specifications are marked up in RDFa, as both RDFa and JSON-LD are RDF formats, you can actually turn this document into JSON-LD with an appropriate too, such as the RDF distiller I maintain. For example, try the following in your browser: http://rdf.greggkellogg.net/distiller?fmt=jsonld&in_fmt=rdfa&uri=http://www.w3.org/TR/json-ld/#abstract.

Geolocation without HTML5 API

All!
I need to determine current user City. With HTML5 it's not a problem. But i need support old browsers (leke are ie 7,8).
First of all i thought to find location using IP address. But its not easy to implement (i need actual database with location). Free web services not provide me needed info. Many of these can determine a country (but not city).
I tried to use http://www.geoplugin.net/ and this service return only Country (as and another free).
I tried to use CSV database with IPs (but in the internet i can find old version).
Do you know free ways to determine user City?
Thanks!
Some older browsers do have some support for getting the user location in some form. Back in the IE7/8 days a few different browsers handled geolocation in different ways. This was a pain for developers. I can't for the life of me remember how to do this in IE7/8 but do remember writing a wrapper library for this at some point. Now a days most people use wrapper libraries that handle all the different browser implementations for them. The Bing Maps V7 JavaScript wraps all the old and new functionalities into a common GeoLocationProvider class in their API which might be an option if you need a map in your site: http://msdn.microsoft.com/en-us/library/hh125833.aspx
You can use our geolocation API https://ip-api.io for this task. It provides data like country, city, zip code
Example request:
$.getJSON("http://ip-api.io/json/",
function(result) {
console.log(result);
});
Example response:
{
"ip": "64.30.228.118",
"country_code": "US",
"country_name": "United States",
"region_code": "FL",
"region_name": "Florida",
"city": "Fort Lauderdale",
"zip_code": "33309",
"time_zone": "America/New_York",
"latitude": 26.1882,
"longitude": -80.1711,
"metro_code": 528,
"suspicious_factors": {
"is_proxy": false,
"is_tor_node": false,
"is_spam": false,
"is_suspicious": false
}
}