Can I paste my Schema.org LocalBusiness info in the head of my webpage or should it be inserted in the body?
My concern is that all those pieces of info are already written somewhere on the page (but not at once) and I don't want to have them twice, once for the markup info, once for the normal reader.
If you are using the syntax Microdata or RDFa, you would ideally apply it to your existing markup. Most of the time you don’t have to duplicate your content.
If you are using the syntax JSON-LD, you add a separate data block (in a script element; see this answer about its placement). You always have to duplicate your content.
Related
I'm trying to learn how Microdata works and I was looking at the Schema.org website and I kinda get how the basics works because you can find some outlined examples online of the Navigations, Headers, Sidebars and Footers - but I don't understand what properties you can use with more complex item types.
Let's say I have an About page on my site.
Nothing fancy, you just talk about your business but there is a item type http://schema.org/AboutPage you can use.
So I visit that link but to be honest everything you see at that page isn't really written down for beginners I think.
Am I allowed to use all the item properties listed on that specific page or only the the selected few in the Thing section at the bottom of the page because the above two sections are part of WebPage and CreativeWork? I don't have the CreativeWork item type on my page, just the WebPage attached to my HTML body tag.
I always thought you could use those item types as snippets in your HTML to wrap pieces of HTML content together and you didn't need to work with an inherited workflow. Going from wrapped content inside WebPage → CreativeWork → AboutPage item types.
How to find the items types and which properties you can use within them?
First note, you can’t use the vocabulary Schema.org with Microformats. You probably confused it with Microdata, which is one of three syntaxes the Schema.org partners support (the other two are JSON-LD and RDFa). (I edited your question accordingly.)
You may use all properties that are listed on a type’s page.
A type in Schema.org always inherits from all its parent types, up to Thing. So, for example, the type AboutPage is also a WebPage, which is also a CreativeWork, which is also a Thing. You just have to use the most specific type that applies in your case.
For finding appropriate types, simply start at Thing and check the "More specific Types", linked on that page. And repeat.
Another way would be to search for some related keywords on the list of all types and check if a suitable type exists.
The problem is if you're unfamiliar with XML and Schemas because schema.org is as friendly as they can be without actually giving more examples of it, simply because stuff like this is indeed complex to make generic enough to reuse, while verbose enough to explain.
However there are some Google tools which can help you learn:
https://www.google.com/webmasters/markup-helper
https://developers.google.com/structured-data/testing-tool/
And register for Google Webmaster Tools account, and use their data highlighter and test.
Use that in combination with the schema.org examples and definitions, and then you'll properly relatively fast start learning which tags to use and how to nest them.
I have a query regarding CQ. Your reply will really make the difference to my understanding.
In other CMS like Vignette, content authors create the contents separately (not directly on the page) for ex. products details and then those contents are iterated / processed to display on the page. But in CQ, the scenario is other way round. Authors directly create the content on the page. Now if same content is needed on other page, how will that be re-used ?
Regards,
Ronak
Content can be reused across pages via Reference components. From the docs:
The Reference component lets you reference text in another part of a
CQ based website (within the current instance). The referenced
paragraph will then appear as if it was on the current page. Instead
of referencing a specific paragraph, the path can also be modified to
specify an entire [paragraph-system]...
There are some other techniques for sharing content and reference data across pages, including inheritance and "data components," described in this SO Q&A.
I get the following errors from the Google Rich Snippet Tool for my website http://iancrowther.co.uk/
hcard
Warning: This information will not appear as a rich snippet in search results results, because it seems to describe an organization. Google does not currently display organization information in rich snippets
Warning: At least one field must be set for Hcard.
Warning: Missing required field "name (fn)".
Im experimenting with vcard and Schema.org and am wondering if I'm missing something or the validator is playing up. I have added vcard and Schema.org markup to the body which may be causing confusion. Also, I am making the assumption I can use both methods to markup my code.
Update:
I guess with the body tag, I'm just trying to let Google discover the elements which make up the schema object within the page. I'm not sure if this is a good / bad way to approach things? However it lets my markup be free of specific blocks of markup. I guess this is open to discussion but I like the idea of having a natural flow to the content that's decorated in the background. Do you think there is any negative impact? I'm undecided.
I am in favour of the Person structure, this was a good call as this is more representative of the current site content. I am a freelance developer and as such use this page as my Organisation landing page, so I guess I have to make a stronger decision of the sites goals and tailor the content accordingly, ie Organisation or Person.
I understand that there is no immediate rich snippet gains, but im a web guy so have a keen interest in these kind of things.
With schema testing, I find it easiest to start from the most obvious problem, and try to work our way deeper from there. Note, I have zero experience with hcard, but I don't believe the error you mentioned actually has anything to do with your hcard properties.
The most obvious problem I see, is that your body tag has an itemtype of schema.org\Organization. When you set an itemtype on a dom element, you are saying that everything inside of that element is going to help describe that itemtype. Since you've placed this on your body element, you are quite literally telling Google that your entire page is about an organization.
From the content of your page, I would recommend changing that itemtype to schema.org\Person. This would seem to be a more accurate description. Once you make that change and run the scanner again, you may see more errors relating to the schema and we can work through those too (for example, you'll probably need to set familname and givenName).
With all of that said, you should know that currently there are no rich snippets that you will gain from adding this schema data. Properly setting this up on your page, is only good to do, especially since we don't know what rich snippets Google or others will expose in the future, but currently you won't see any additional rich snippets in Google search results from adding these tags. I don't want to discourage you from setting this up properly but I just want to set your expectations.
I often face a problem when I need to encapsulate some far apart fields in one form, and the fields in between them in other forms. Or encapsulating first two rows of a table in form and other two in other forms and so on. But of-course this is not allowed in standard practice. My question is why such tags like form (and other non displaying tags) have to be treated as "displaying" tags, and they also are restricted to be used at some places. Is there any genuine reason.
PS: what I was thinking about form in particular, that I define as many forms as I want at a single place, and give their references (eg ids or names) to the corresponding fields. That way form tag does not have to interfere somehow with the location of fields?
Asking "why" questions of HTML behaviour is not normally a useful activity. Very often the answer is "because one of the browsers originally did it that way and we're stuck with it for backward-compatibility reasons".
Note also what #DanMan says about the displayability of <form>.
However, your description of declaring forms in one place and then having the controls associate with the forms by id, is very similar to what has been done with the HTML5 form attribute. The only difference is that the controls reference the forms, rather than the forms referencing the controls. All we need to do now is wait for implementations in the browsers.
How is a <form> a non-displaying element? You can apply all kinds of CSS on it, and they will show up. It's just that they usually have no default browser styles. It's a rookie mistake to wrap elements in <div>s and styling those, when the only thing inside them is a single element.
<div class="myform"><form>...</form></div>
<form><div class="myform">...</div></form>
Both equally superfluous. Just style the original element directly.
<form class="myform">...</form>
Now, before you jump on my back: I'm not saying you're doing that. Just a general advice.
About restricted usage: that's probably to make it easier for implementors (browser creators) and for backwards compatibility.
I have made a simple blog using Node/Express/Mongo/Jade (and/or HAML.js). I used (and slightly updated) the blog app from this tutorial, which itself an update of one from howtonode.org
I can render attributes such as links, etc., with the template engine just fine, but when I pass data from the db, none of the html renders. I get plain text print-outs of the HTML. I figure I need some other node packages/modules to render the 'dynamic' content, but I don't know where to start.
In jade, when you're passing content you DON'T want to be escaped, be sure you pass it along as != instead of =
BE EXTREMELY CAREFUL THOUGH! If you don't manually parse out the bad stuff, you could make your website extremely vulnerable.
You can read some more jade documentation here