Tip:
Highlight text to annotate it
X
Jordan: Hi, I'm Timothy.
This is Scalable Structured Markup.
Who here knows what that means?
A couple of you.
All right, well, I added another title,
because I thought maybe I'd make it a little bit more clear
what this talk is really about,
and it's about putting more knowledge into your site.
I think that's a really interesting idea,
and over this, the length of this talk,
we're going to look at different ways to do that.
We'll see that putting more knowledge into your site
can be as simple as just identifying the data
that is already there and not adding anything new,
just be like, "This is what it is."
The richer the markup, the more control you have
over how your site appears
and the more cool things that can be done with that data.
By the end of the session,
you'll be able to mark up your pages
so that they can appear in search engine results pages
with Rich Snippets.
You'll be able to test that markup,
and you'll be able to tell Google
how often it should crawl certain pages
and when things change.
This is all about getting more control over your site,
how your site appears in search results,
and when it gets updated.
And, of course, at the end of the talk,
I'll give a better understanding
of maybe where this is all going.
Does that sound like fun?
You all just had lunch, didn't you?
[laughter]
All right, so here's some interesting bits of information.
Up there are the hashtags.
If you would like to tweet this session,
I encourage you to do so.
These are some hashtags to identify your tweet.
Also, there's a link for feedback.
I'd love to hear how you feel about the session,
and there's a link to where the session is going to live
after today.
That's me. Hello.
I'm a Developer Advocate at Google,
and you can find me online, and you can @mention me
@timothyjordan.
All right, so today this is what we're going to talk about.
We're going to look at the past.
Where does it all come from?
We're going to look at the present
using Rich Snippets and using Sitemaps,
and we're going to look at the future.
What's next for all of this markup?
So, the past.
This is how the Web looks,
oh, I don't know, circa 2000 or so.
You edited some pages.
You uploaded them to your server,
made a Website.
Google crawled those pages, when it felt like it,
and returned links to your pages, as appropriate,
on the search engine results page.
The problem was that the Snippets on the results page
were relatively boring.
I mean, they were a good summary of the page,
but they didn't share the richness
of what those pages actually had on them.
Every page looked the same,
and you had no control over how it looked.
So, the question was, how could you get more control
over the search engine results page?
How could you get it to know more about your site,
and how could it provide that knowledge to the user?
That brings us to today, the present.
Your site probably looks more like this, right?
You've got a database on the back end
that drives your pages.
You can mark up those pages,
identifying the data that's already there.
Google, when it crawls those pages,
can then see what's on those pages,
what actually those items are,
and it can display those to the user in an interesting way.
Maybe that page is a recipe page.
It can show a recipe Snippet.
It can add ratings where they exist.
It's the richness of that data that you get a say in now,
and we can do some other cool things with that data
that we'll look at a little bit later.
All right, so let's talk about Rich Snippets.
We'll dive into this topic.
Rich Snippets have been around for about two years.
In fact, two years two days from now.
And over that time--you can see I have a timeline,
because this is a presentation, and you need a timeline.
On my timeline, you can see that over the last two years,
we've been steadily introducing
different types of Rich Snippets,
and we've been introducing different ways for you
to mark up those Snippets that we recognize and will crawl,
from recipes to events to prayer times last week.
So, here's a couple examples. This is a search for stuffing.
And you can see I'm looking for stuffing,
and I get this response.
This is on the whole page. This is one of the responses.
And you can see the richness of the data in this Snippet.
You've got a rating,
and we know how many reviews that rating comes from.
We've also got a clear description there as well.
So, when the user looks and sees summary, summary,
and then a Rich Snippet, that really stands out to them.
Here's another example.
There's a search for Drooling Dog Bar-B-Q.
And, of course, I got 26 reviews,
and I also have a price range,
what you can expect to pay at this restaurant,
and I've got bread crumbs,
which locate this page in that site.
We know that this is a barbeque restaurant,
and we could probably also navigate
to other barbeque restaurants.
And in some cases,
we can combine Rich Snippet data with other data we find
to further increase the richness of the experience.
And you see a really nice description at the top,
and you'll also see some other data that we found,
like an image and other places where this is listed.
So, those are Rich Snippets,
and you can see the value of this to your user,
and you can see how that would translate
into more traffic and a better experience.
All right, so let's drill deep.
Let's look at some markup types.
Now, with standards, in general,
there's always very strong opinions about which is best.
And I'm not going to tell you which is best,
but I'm going to give you some pros and cons
for three types that we read and we'll scan for
when we're looking for structured markup on Web pages,
the first of which comes from RDA,
and RDA has a really great design.
It comes from XML tradition, and it's very general.
You can express a lot of different things with RDA--
sorry, RDF.
There's RDFa that does an attribute-level mapping
of RDF to XHTML.
And that's cool.
So you get all the power and design of RDF.
The problem, though, is that sometimes this can be
a little confusing to write,
and, in fact, in user studies with Webmasters,
they found the nesting structure of RDFa
to be particularly confusing.
That's when, say, you have an entity such as an event,
which includes an entity such as a location
that's nested inside the event.
That particular markup can be a little confusing.
Another option is microformats,
and this is just a different place to start.
Publishers generally say this is easier
to identify their data in existing HTML docs
using microformats, but it's not as general as RDFa,
so you can't express as many things.
And there's one more-- microdata.
And microdata has the general expression
of entities like RDFa,
but it also maps more easily to HTML,
and this is my preferred method.
I like it, mostly because when I'm reading an HTML document,
I can parse this easier,
and so maybe that's just a personal preference.
This is the one that I'll be using in examples today.
Speaking of which, let's take a look at an example.
I want to give you a URL first,
and this is the Rich Snippet testing tool.
It's at /webmasters/tools/richsnippets.
It's a really cool tool.
You can go there and put in any URL,
and it'll tell you what data that it finds
and gives you an example Rich Snippet,
if it can find enough data to construct one.
Also, on the left of that page is a link to our documentation,
which will clearly list out
all the different types of structured markup
that we'll look to and map to a Rich Snippet,
and what are the different parameters
that are required and optional,
and it also gives examples for each.
And, again, this is what a Rich Snippet looks like.
We're going to do an event.
These are the properties for the event.
I'll come back to this table several times,
so don't worry about copying it down real quick,
but you can see there's a number of different properties,
and they're all pretty straightforward,
from summary, to URL, to location.
This is a page without markup,
and it's as we would expect a very simple HTML page to be.
We've got some data,
and we've got some very, very basic formatting
with line breaks.
I'm going to take a look at this page in the Snippet tool,
just to get a default baseline expectation.
So, I've got structured-markup.appspot.com.
This is just a static app engine site,
so I've thrown some static files onto app engine,
so that you could play with them, if you'd like.
You want this URL.
Oh, you want it bigger.
How's that?
Okay, thank you.
The no-markup page looks like this,
and you can see it's very basic.
I just have some line breaks in there.
It's not pretty at all.
I wanted to make sure it was super basic
so that we could see the markup as it gets in there.
I'm going to go ahead and copy this URL and paste it
into the Rich Snippets testing tool,
and you can see there's insufficient data
to generate the preview.
That's what we'd expect, right?
We don't expect it to find anything,
'cause, well, there's nothing to find there.
So, let's take a look at it with some data.
I'm going to add in three bits of data--
the two required types and one of the recommended types.
And I really strongly recommend you add a location
to your event as well.
We've got a summary up at the top.
That's required.
And we've got the start date down there in the center,
also required.
And the location, of course,
is where this event is taking place,
and that's going to be a nested entity.
Adding the markup, it looks like this.
And let me take you through it line by line.
At the top, we've got an itemscope.
That itemscope is super important
and really basic.
If you have a div tag or any tag
that surrounds all the data for that entity,
that's where you put the itemscope attribute,
and it's going to tell readers that everything inside,
everything a child of that tag, is the scope of this item.
Does that make sense?
Oh, good, there's nodding. I like that.
The next thing is we've got an item type.
We just got to clearly indicate
what kind of entity this is.
In this case, it's an event.
Now we've got item props.
This is the item property.
We've got three, as I mentioned--
summary, start date, and location.
And the data contained in those tags
corresponds to that parameter, that property.
Let's take a look at the nested one down here at the bottom.
You'll notice that I have, next to the item prop location,
another itemscope and item type.
Since it's nested, we're going to add another entity
inside that parent entity, so it'll need an itemscope
and an item type to indicate it.
In this case, we're going to list an organization
as the location of this event.
And, of course, it has an item prop.
I've just added one-- the name.
That's required.
So, let's take a look at this live.
I like saying that.
Over here, I'm going to the required markup link,
and it looks like this.
Notice, it's the same Web page.
I'm going to copy this
and paste it into the Rich Snippets testing tool,
and you'll see we have new output.
We've got, here in the center, the Google Search preview.
So, if we were to return a Rich Snippet
in the search engine results page,
it might look something like this.
And down at the bottom is my favorite part.
It tells us all the data that it found.
So, if we thought we were marking something up
and it's not listed here,
there's a problem somewhere along the way.
Likely, we put in the wrong item prop,
or we put that attribute in the wrong place,
or it was looking for the value somewhere else.
And so, at this point, we'd look back at our code
and see if we could find the error.
Really straightforward, right?
Okay.
All right, let's add in a few more properties.
You'll notice some of these properties
are going to change how the Rich Snippet looks,
and some of them aren't.
But since we have the data, we might as well mark it all up.
So, in this case, I'm going to add a URL,
the description, the end date, and the event type.
All of that data was already on the page,
so I'm just going to mark it up,
and it'll look something like this.
And you can see I've added the description right there,
added the item prop and a span.
I've added the end date.
Both those dates have the ISO time
and then a readable time.
And down here at the location, I have the locality.
Oh, and an event type down there at the bottom.
And we'll take a look at what this looks like.
So, you can see a couple things have changed.
One, I have a lot more data down at the bottom.
Another, up at the search preview,
you can see it's added the locality to the location.
So, a number of things didn't make it to the Snippet,
but it's still good that we've indicated to the world
that those are on the page,
and maybe we can take use of those in the future.
But then some things do update the Snippet.
See how that works?
And all I've done is added a few attributes
and a couple span tags to surround data.
I've not added anything to the page,
other than markup.
So, let's talk about scaling.
This is the easy part, actually.
If you've got a site like this,
where a database backs your pages,
and, hopefully, that database is a field-level database.
If it looks something like this, then it's easy.
Likely, you're not writing your pages.
You're editing templates.
So, where we have the summary, location, and start date
in an event field in some database,
we can just add those to the template
and make sure that the markup's there.
When we change the template for, say, product pages--
maybe there's 5,000 of them on our site,
but one template-- we mark up that one template,
and all of those product pages get the markup.
This is kind of obvious,
but I think it's important to note
that when you edit your templates
to include this markup,
you've added it to your whole site.
Another thing, Sitemaps.
This is also kind of a scaling issue.
We'll get to that. This is where we are.
We've got a database driving a site,
driving the Google index, driving search results,
and the Google index will find pages on our site
as it can and when it can.
But wouldn't it be cool if we could tell Google
what pages are on our site?
These are all the pages I want you to know about.
Wouldn't it be also cool if we could tell it
these pages change daily or these pages change weekly?
And that's what Sitemaps are about,
and they've been around for a while.
Essentially, you've got your database driving your Sitemap,
and your Sitemap goes to the Google index,
and then Google knows when to look for new data
and where to look for new data on your site.
Let's take a quick look at an example here.
First off, links-- super important to have links.
Sitemaps.org is where you can go to for the spec
that Google and other search engines use,
and you can use /webmasters/tools
to get a little bit more control
over the Sitemaps that Google sees.
A typical Sitemap has these properties.
You've got a URL set that encapsulates everything,
and then you've got URL entries.
In those URL entries, you may indicate the location,
the last modified date, the change frequency,
and the priority of the page.
All these are really straightforward.
The one that I do want to mention particularly
is the priority.
This is a scale from 0 to 1, and by default, it's .5,
and they're relative to each other.
So, if you list all your pages at 1,
you haven't really done anything.
But if you tell Google this page I want you to have
a bit more priority for, say, my home page, right,
then maybe some of these product pages
that are only updating monthly.
And this is what the example might look like.
So, I've just added in the home URL of the examples
I've been using so far on app engine.
I've added in a date, that it changes daily,
and I've added the default priority.
And, of course, this is really easy to expand
to include the other pages on my site as well.
And maybe once I add those, I realize my homepage is a .8,
and these other pages are a .7, just slightly less in priority.
And that slide came a little bit early.
I want to introduce something really, really cool,
but first, let's look at the tool...
which is here.
So, I've got a couple Websites in Webmaster Tools.
And I go to site configurations and Sitemaps.
Now, in Webmaster Tools,
before you can start doing anything,
you need to have your site claimed.
That site needs to be yours, and that's so not anybody else
in the world can start telling Google
about your site for you, when you don't want them to,
and that can be as simple as adding a little file
in the root directory of your Website.
Google scans that
and knows that you have right access to your server.
Once we've done that, we can submit Sitemaps,
and that's what I've done here.
I've gone to submit a Sitemap, and I've entered in my URL,
and that Sitemap appears.
And every time that Sitemap changes,
I can come back
to Webmaster Tools and hit "resubmit,"
put a check mark next to that Sitemap and hit "resubmit."
That's cool.
Google will know the data that I want available,
and it'll know when I feel
it should take a look at that data.
You can do Sitemaps with feeds as well, which is pretty cool.
And once you start using feeds, you might start to think,
"Wouldn't it be cool if Google can know
about my data on my Website as it changes?"
I've got a database backing a feed.
That feed updates as my database changes.
It would be cool if Google would know every time that happens,
and that's the slide I showed you.
We have another thing available to us called PubSubHubbub.
Who here knows what PubSubHubbub is?
A lot of you! That's great.
So, I've got a bunch of slides that are going to be review
for all of you that raised your hands.
We're introducing today that our Sitemaps
and Webmaster Tools will support PubSubHubbub.
So, when you put a hub in your feed
for the Sitemap of your site, Google will read that
and subscribe to that feed and get those real-time updates.
It will then know that your site
and that Sitemap are ready to crawl.
It pretty much looks like this.
You have the Sitemap. You add in PubSubHubbub
so that a fat ping just hits Google
every time something happens,
and then Google knows that your site is updated
and can check it when it can.
All right, I'm going to go through PubSubHubbub quickly,
because there were a lot of hands.
Slow me down if you don't get anything.
PubSubHubbub is a really straightforward protocol
that solves a very specific problem.
If you have a feed--
And I want quick, timely updates about that feed,
before PubSubHubbub,
what I would do is pull that feed.
Every 30 seconds, or 10 seconds,
I would download that feed again,
and I would say, "Has anything changed?"
If nothing's changed, then I don't do anything.
If something has changed,
maybe I bubble that up to a user-facing action.
But the problem here is that you have
lots of publishers and subscribers.
Let's say 1,000 subscribers to one publisher,
and all of them are asking every 30 seconds,
"Are we there yet?" Right?
This would be annoying for a road trip,
and it's annoying on the Internet, as well.
Wouldn't it be cool if the publisher
can just tell the subscriber, "Yes, we're there"?
And that's what PubSubHubbub does.
It works with three things-- a publisher, a subscriber,
and a hub.
Get it? PubSubHub.
And, of course, the "bub" is just for fun.
What will happen is
the subscriber will ask the publisher,
"Can I have your feed?"
The publisher will respond and include a link to their hub.
If the subscriber is PubSubHubbub aware,
it will then subscribe to that hub,
and this hub will do a little bit of a dance
to verify that the subscriber actually was subscribing,
and it wasn't an attack to overload them with data.
So, it'll say, "Are you sure you wanted this?"
The subscriber will say yes.
From then on, the publisher
is going to send data to the hub,
and it's going to do it one of two ways.
Either the publisher will notify the hub directly,
or the hub will continually pull the publisher
in that pulling method, which isn't a big deal now,
'cause now there's just one person pulling,
and that person can do it at a much higher frequency,
and that publisher will give it the data.
Once the hub has the data, it sends it to the subscriber.
That's it.
It just pushes out a fat ping and a post.
This is your data. This is the update to this feed.
So what'll happen is, when your site has an Atom feed
and it has a link to a hub, when Google subscribes to that,
every time you make a change to your database
and that gets updated in your feed,
that feed will push out to the hub.
It will then push out to Google...
right through.
Pretty cool, huh?
And Google will then know that it can recrawl your site.
And, of course, this works.
PubSubHubbub is a great protocol that works at scale, too.
So it can work with a huge number of subscribers.
Let's take a look at a quick feed.
This is an Atom feed with a link,
which is just right up there.
It's a link, a real link to the hub.
And this is actually a live feed.
If I go to...
I made a blog.
It doesn't really have anything interesting on it,
except, for our purposes, this link down here.
Blogger, as it turns out, has an Atom feed by default
that includes PubSubHubbub.
So, I can actually take this link
and go to Webmaster Tools,
and you see I've added in that link to that feed,
and it is subscribed through PubSubHubbub.
I was actually playing with this last night.
I would post a new message on my blog,
and then sometime later,
I would just see it automatically show up here.
Pretty cool, huh?
So, that's pretty much all you need.
You create a Sitemap feed,
and that can be an RSS, mRSS, or Atom.
Use a hub, a PubSubHubbub hub and indicate that in the feed,
and then add the link in Webmaster Tools.
Data in Webmaster Tools, by the way,
is updated after Google crawls the site.
So, there may be some delay in actually updating your blog
and seeing that in Webmaster Tools.
Don't expect it just to pop up.
All right, so let's talk a little bit about the future.
What's next?
So, this is us with Rich Snippets,
and PubSubHubbub Sitemaps.
We've got a database-backed Website
that pushes to the content of our pages,
and that markup is also structured
so that those entities are identified on those pages.
The database also updates a Sitemap,
so Google knows what our content is and when it changes.
And then we've got this cool stuff
over in the search engine results page.
And what we can expect in the future, for sure,
is more Rich Snippet types, perhaps.
We just added prayer times,
and there's a lot of different discreet entities
that would be cool and interesting to show
in the search engine results page.
We're also going to do more with that data.
For example, we can include that data in vertical searches,
and we've just recently released this feature.
I don't know if you've seen it yet,
but I had a screenshot earlier of a stuffing search.
You'll notice, when I look down here at the left,
I can narrow my search by ingredients,
and that's because these Webmasters have identified
the ingredients in their recipes with Structured Markup.
So, as I select, say, I don't know,
turkey, maybe I don't have turkey.
Maybe I have sherry, and maybe I have steak.
Here is a grilled flank steak with mushroom stuffing.
That sounds fantastic.
And I can indicate I don't have more than 60 minutes.
Apparently, that takes a while to cook,
or the other fear is that it doesn't exist for my diet.
[laughter]
You can see how this is really cool,
that we can do not just Rich Snippets.
Not only do you get more control over how you look
in search engine results,
but we can do cool new things with that data,
like this vertical search with recipes--
and it all starts here.
By mirroring the data in your database
on both your Web pages and your Sitemap,
and on those Web pages using Structured Markup,
your Website becomes more like your database.
By telling Google this right away,
that data is more known
and more useful and available for your users.
The more this happens, the more the whole Web
starts to become more of a database,
the more we can start to do really cool things
with that data.
Pretty cool, huh?
All right, so, to summarize,
the practical elements of this talk is markup is super easy.
You don't have to add anything new to your site.
You just have to tell us what it is.
Scaling is pretty straightforward.
All you really need to do is edit your templates
instead of the end pages.
Markup is good. Yeah?
Rich Snippets are really cool,
and vertical searches are really cool,
and users appreciate them.
Not only that, but you have more control.
You now get to tell Google what data is there,
using Sitemaps and using structured data,
what data is actually on the page
and what pages have data.
And, of course, the Sitemap tells Google
what pages should be crawled and when they've changed,
so they can update them.
And this all leads, again--
this practical application that happens today
is more control over how you appear,
and Rich Snippets and Sitemaps give you that.
It allows you to control traffic and engagement,
and it gives you more control so that using that control,
people know what's so great about your pages.
You let your users see the richness of every page
when they're looking for them.
I think that's pretty neat.
All right, that's pretty much all I have to say on that,
except for the answers to any questions you may have.
I hope that was interesting and straightforward,
but I would love to talk about it further.
So, we have a microphone in the center
and a microphone way over there.
And if you want to go up and ask some questions,
I'm here to answer them, and we have some other Googlers
who are experts in this area here
available to answer as well.
Daniel up here might be popping up and saying hello.
Yes.
man: So, if we've got a new kind of entity
that we wish Google would make into a Rich Snippet--
Jordan: Yes?
man: We happen to be a real-estate site.
We would like "three beds, four baths"
to appear in a Rich Snippet.
My understanding, will we need to build an industry consortium
to make a standard around the microformat?
Is that step one?
Jordan: Well, there's two things.
One is being able to identify the data,
and, yes, you've indicated that, right?
Like having microformats or microdata
able to specify that is great, and microformats in RDFa
are really good for this,
because they're already pretty general.
The other thing is convincing Google that that would be, like,
good for the users.
And so the best step there is to go to the Webmaster Forum
and make it known, "This is a Rich Snippet
that we think would be really valuable to the users,
and we're ready to mark this up,"
or, "We've already marked our pages up with this."
Would you add anything to that?
We can share a mic.
Daniel: I've never talked to your chest before.
[laughter]
Jordan: I'm sure they can bring up a mic in a sec,
but I'll hand this over to you.
Daniel: Great. Thanks.
Yeah, I think that's a great direction
that we want to pursue in the future.
One of the great things about both RDFa and microdata
is that you don't have to form an industry consortium.
You can mark up the data that you already have
on your page in a forum that makes sense to you.
That starts the conversation, right?
That starts the conversation when you post a link
in a Webmaster Forum.
That starts a conversation with other Webmasters
about what data is interesting to other sites.
It starts a conversation with Google
about what you're able to mark up.
So, I would say that that's the beginning--
thanks a lot-- and over time,
we'll have some better answers to this question.
It's a critical part...
Jordan: Hello, hello.
man: Well, I'm certainly open to the idea.
What you just described is,
"Oh, you should just mark up your site,
"and then post in the forums.
Maybe someone will notice."
I'm not sure if anyone's going to notice--
A random post on the Webmasters Forums?
Really?
Jordan: I read the forums.
[laughter] man: All of them?
They get a little noisy sometimes.
Daniel: Seriously, there are a lot of people at Google
who do read the forums.
But, yes, I think you've really highlighted an issue
that this is a person-to-person negotiation right now, right?
That part is not scalable.
That's why Timothy's talk on Scalable Structured Markup
didn't include that topic.
And so, yes, it's socialization.
It is developing a groundswell of support,
but we recognize that that's not ideal.
So, we look forward to coming up
with better answers to that over time.
It's a serious problem that we recognize.
[man speaking indistinctly]
man: That is an industry consortium.
I need to build an industry consortium of people who--
man: It's not an industry consortium.
It's a Wiki page that you go to and a process that says...
man: Okay, I'll post on the forum,
and I'll post onto Wiki. Maybe someone will notice.
Daniel: Gentlemen--
Jordan: Clearly, we all feel passionately about this.
We don't all have microphones.
Daniel: So, please, yes,
please come up afterwards and chat.
Jordan: Yeah.
Daniel: I would love to have a longer conversation with you
about how to make that work better.
man: All right, thank you.
Jordan: Yeah, please do.
[man speaking indistinctly]
Jordan: All right, let's go over here
for the next question.
man: A common response that I see on my test page--
on my test page or the testing tool that you have
is, "We couldn't find the subject of your page."
So, I've included maybe too much structured markup,
and I wasn't able to tell you the exact subject of the page.
Say, it's a profile page for a person,
and I really want this to be the highlighted noun,
and I included too many of Spinal Tap's upcoming concerts
in the sidebar and videos or whatever else.
So, what do you recommend for highlighting--
It could be an area roll or something--
the subjects of the noun that you really care about
for that page?
Jordan: That's a very good question.
I don't have an immediate answer, do you?
Daniel: Yeah, that markup, ideally,
in a large scalable site, right,
you have records in your database, as Timothy described.
You have records in your database that describe
each part of the page.
Focus on, you know, what that page is about.
Focus on the record that backs it.
This markup is really specialized right now
to pages that are single-item pages.
It's possible to do more, but, honestly,
Google isn't so good at that right today.
Jordan: That's a really good point.
When you markup your pages,
do you open up the Webmaster Help Center article
for that Rich Snippet type and try and hit that,
or do you just add the data?
man: Yeah, and I go to your data-vocabulary.org
and read the exact specs to what I should be putting on there.
Jordan: So data-vocabulary.org is great,
but if your goal is Rich Snippets,
at least in my personal experience,
editing and adding the structured markup,
the Webmaster Help Center pages will give you an example,
like, "This is a Snippet that,
like, could give a Rich Snippet on search engine results pages."
Does that make sense?
Whereas Data Vocabulary is the spec,
and it's like everything you can do,
the Webmaster page will say,
"This is something that--this is a good example of the page
that would get a Rich Snippet."
Daniel: It sounds like you have a particular problem
that we're not serving very well, so--
man: I think I'm too expressive, and you're asking me
to just dumb it down for you, and so I'm wondering how--
Jordan: That's hard.
man: And so I'm wondering how do you change for time?
I've heard, like, "Oh, they notice
"when something comes up in the testing tool
that didn't quite work out."
Kind of like the forums question--
Do you tend to see that that happened?
So, if I list Spinal Tap, and I say bands like Spinal Tap,
and each of those has a little person markup within them,
but the main object is Spinal Tap,
and there's so many different things you can do,
where it's all valid markup.
It's all very descriptive, but it might take away
from you finding the exact subject of the page.
Jordan: So, to Daniel's point, yeah,
it sounds like that there is a conversation to be had here,
and there's some changes that we could make
to better address your use case.
So, if you wouldn't mind, come up afterwards,
and we'll talk about it in more depth.
Yes? man: I want to thank you
for the prayer times in the Snippet.
Jordan: Oh, you're welcome.
man: I saw the talk this morning,
what places API from Geo.
So, the question, of course, is,
how do we add the places information
and inform through the Webmaster site tools?
Daniel: So, I'm not sure that I grasp your question.
Jordan: I think the question is,
how can you add in places information?
man: Places API that they announced this morning
on Google Maps.
Jordan: So, what's the end goal?
By adding in this information, what do you want to see happen?
man: So, if I have a Website that has got different events
at different locations or places that I manage and control,
so I can upload that information.
Jordan: So, there are a number of different ways
that you can address that problem,
and one of the ways is to add Structured Markup.
And I believe there is another way
that we can get local information to Google as well.
Daniel: Yes, the local story--
there are a couple of different ways
to provide local information,
and one is through Google Places itself.
Jordan: Mm-hmm.
Daniel: There's a feed format for local places.
So, if you want to use the Places API today,
that's probably the best place to do that.
man: Okay.
Daniel: If your audience is more a broader Web audience today,
the best place to do that would be Markup on a Web page.
man: Thank you.
Jordan: Thank you.
And over here.
man: Hi. I'm curious.
How many of the new HTML5 tags
will Google's search engine recognize,
like, article, section, nav,
footer, header, things like that?
Jordan: In general, we'd like to use
as much data as available,
and that includes all different kinds of markup types.
And when we find a good use case for that,
then we'll start reading data.
I don't have any specific information beyond that today.
Daniel: Yeah, the only thing I'd add to that is
there's a difference
between the level of structure that's expressed
and the level of richness that's expressed
in those HTML5 standard tags
and those that are really necessary to hoist
more information onto the search results page
to make your page stand out, to make your site stand out.
There really isn't much that we have been able to do
with the article tags,
as they're used on the Web today,
you know, because many people use them incorrectly
or use them even on things that aren't articles and so on.
So, that's something that we're continuously looking at
in Search to see how we can use them.
man: Hi. I was wondering if you know to what degree
some of these technologies,
like Rich Snippet support and PubSubHubbub
are supported in products like the Google Search appliance
for Internet search,
so we can do this kind of thing with our local content?
Jordan: So, maybe you could speak to the search appliance,
but for custom search engine,
you definitely can use Rich Snippets
to affect how those look on your own custom search engine.
And, in fact, we take it even a level further
with custom search engine and give you even more control
over how everything looks, using page--
Daniel: Page maps. Jordan: Page maps.
That's the one.
Daniel: Yeah, sorry, I don't know about how this relates
to the Google Search appliance,
but I could take your card afterwards
and put you in touch with someone who might.
man: Okay, thank you.
man: If we were to add a PubSubHubbub Sitemap feed,
should we then remove the old style standard Sitemap,
or should we keep them both?
Jordan: Well, so, not everybody out there
is going to support the feed and PubSubHubbub,
so it makes more sense to include both
and just have your database drive them,
so you don't need to worry about them,
and then tell Google about the one
that you want Google to use.
man: Got it. So, Google's crawler can use both,
and you can say, "Opt for this one."
Jordan: Yes. man: Okay, and--
Jordan: Just indicate that in Webmaster Tools,
which one you want Google to use.
man: Right.
I think that I've noticed in the past,
you know, that we put a lot of links on our Sitemap,
and Google will crawl some of them,
but not necessarily all of them.
If we use PubSubHubbub,
is that a good way to make sure that at least the freshest stuff
gets crawled more consistently,
or does it not necessarily impact that?
Daniel: Right now, it doesn't impact that at all,
but one of the advantages of PubSubHubbub
is that Google has tighter correlation
between when pages change on your site
and when we know pages change on your site.
So, that puts us in a situation where we can, over time,
learn better page-change rates than we can right now.
So, from a practical perspective, it won't help you
get those pages indexed faster right today,
but it puts us on a path where we can do that in the future.
man: Thank you.
Jordan: Hi, Monica.
Monica: Hello.
So, I love the support for Microdata.
I was wondering if Google would consider ever supporting
the Open Graph Vocabulary with Microdata
and, in general, if you're going to be supporting
the Open Graph Protocol via Meta Tags at all
for this Rich Snippets.
Jordan: Go for it.
Daniel: Yeah, so Open Graph Protocol
is a type of RDFa.
It is a subset of RDFa,
so from a markup language perspective,
there's really no barrier.
One of the--the deal, as Timothy described it,
for Rich Snippets is a site describes what their site
is about in more detail,
and in exchange, the site gets richer results in Search.
So, right now Open Graph Protocol
is not ideal for expressing what a site is actually about.
It's very UI driven, with the exception of locations
and the new effort in products.
It's really focused on, here's an image,
here's a title, here's a description, here's a URL.
And we've found, over time, that that doesn't--
communicating with users in a search engine at that level
doesn't help people make decisions of what to click on
on the search results page.
I think that makes a lot of sense for the stream,
but makes less sense on a search results page.
On a search results page, having richer information
about, for instance, ratings, for instance,
what--the specifics that are encoded in a prayer time
is much more useful.
And, so, we haven't seen that benefit right now,
but we're constantly looking, right?
And there are a significant number of pages
with Open Graph Markup, so there's a lot to look at.
Monica: Okay, great, thank you.
man: So, Google tends to put
less emphasis on invisible markup,
things that are like in Meta Tags and the Head.
Yet Rich Snippets supports things like Meta Elements
inside of your item.
So, I'm wondering, how do you view a span versus a meta,
for example, if you're to describe your data,
and things that might not be very useful to the visitor
of your page, like the Geo coordinates
or the war field, in your example,
but could be interesting in your Rich Snippet data?
So, how do you weigh those decisions
and whether it just isn't ranked that highly when you view it
and try to get information
versus what's not really useful to a visitor?
Jordan: So, I'll take a hack into that,
and then I'm sure Daniel will add--
is that when you look at a page,
the stuff that the user sees is generally a better indication
of what that page is about to that user,
and so, in general, we encourage Rich Snippets
to mark up data that is, in fact, visible to the user.
Daniel: Yeah, I would only add that,
as you mentioned, in the case of, say, Geo coordinates,
there are some cases where that doesn't apply so well.
Yeah, so we look at the information
that's on a Meta Tag,
but we really encourage it to mark up the content
that the viewer sees.
Jordan: Cool.
Well, I guess we got no more questions for the microphones.
We'll go ahead and end here.
And I know I, and I think Daniel,
will be around for a little bit longer,
if you have any questions for us directly.
Thank you so much.