Tip:
Highlight text to annotate it
X
Hannah: Hi. Welcome to Distilled Live. My name's Hannah Smith and this is Bridget Randolph,
and today we're going to be talking about something called content everywhere, which
is pertinent. Cisco just released some data saying that last year's mobile traffic was
nearly 12 times the size of the global Internet in 2000. Definitely there's something to be
said for device diversification. hat's hard to get your mouth around. So yeah, so content
everywhere is something that I've kind of heard about, but I'm not sure what it really
is. Maybe you can explain it for us.
Bridget: Sure. I mean, most of us by now are aware of this idea of mobile design, responsive
design, and all these sort of tools that we can use to make our websites more flexible,
more mobile-friendly, more multi-channel. And that's really fantastic. It's really important.
But, in a way, that's only the first part of the solution, because as we begin to see
more and more different types of devices, different ways of accessing our web pages,
what we're starting to realize is actually, there's two parts to this. There's the web
page itself, which is sort of the layout that you see when you access it. There's also the
content on that web page. And they're not actually the same thing.
Hannah: When you say content isn't the same as a web page, those are things that are hard
for us to distinguish, I think, given how we're used to publishing right now. Could
you give us some clarification on what you mean by that?
Bridget: Sure. I mean, I think just an easy example is a sidebar, right? A sidebar is
a layout element. It's an element of a webpage. But we could put all kinds of things in a
sidebar. We could have a timeline. We could have a list of related topics. We could have
a list of other posts by this author. We can even have our call to action button. So we
can't just say this is a sidebar. We also need to ask, "Well, what's the content that
we've put in the sidebar?" And that's how you're separating it out.
So getting back to the responsive design concept, the responsive design for the web page, we
say, "How do we deal with the sidebar?" Content everywhere, which is sort of responsive design
for content, would say, "Actually, how do we deal with content if it's a call to action?
How do we deal with it if it's a timeline? How do we deal with it if it's related links?"
And so on.
Hannah: Do you have an example of that, perhaps, in the wild? So perhaps somebody who implemented
responsive design, but perhaps has missed something?
Bridget: A great example of this would be, actually, Starbucks, who have made a beautiful
website. It looks great on a desktop. They've made a beautiful responsive design, so when
you look at it on your mobile, it looks great. But what they haven't thought about is, in
rearranging these elements on the page layout, they haven't thought about how their content
fits into that layout. And what they've done on the desktop is put their call to action,
one of the most important elements of their product page, they've put in the right-hand
sidebar. Now, in the design, they've decided to move the sidebar, when it shrinks the screen
width, to move that sidebar to the very bottom of the page. Fair enough. It's a pretty standard
thing to do in a responsive design. What they weren't thinking about, though, is having
a call to action in the sidebar means that when that page shifts, suddenly their "Buy
Now" button is no longer visible.
Hannah: I think that's a great example, not the least because they've kept all of their
social sharing buttons at the top. So you can tweet about these coffee beans. You just
can't buy them on a mobile, unless you're willing to scroll and scroll.
Bridget: And I think that highlights, as well, this problem of responsive design, because
it's limited to the layout, and so it's not thinking about the purpose of a given page's
content. And I think, for instance, if it was a blog post, having those social links
might be the most important thing. You might want people to be tweeting it. For a product
page, it's not so great. You want people to buy it. Those are the sort of things that
you can get more granular with if you're looking at it in terms of the content meaning, rather
than just the page layout.
Hannah: We're talking about identifying key elements. So purchase buttons, share buttons,
author, whatever. How does that work in real terms? Like, what are we actually doing with
that content?
Bridget: There's sort of two parts to what you need to do to implement this type of system.
First, you have to figure out what the content is, what it means, what you're trying to achieve
with it. And then you actually have to put it in a structure that is readable to the
web browser or whatever else is rendering it. So you're going to start by figuring out
what you have. You do a content audit. If you have a lot of stuff on your site, that's
probably your first step. Then you're going to take it and look at what the different
pieces are. By that, I mean you might have a blog post. You might have a recipe. You
might have a review. Those are all very different, and they're going to serve different purposes.
So you want to break those out, and those are sort of your types, your broad, top-level
categories. Finally, you're going to take each type and sort of do the same thing, and
say, "What are the building blocks? What are the basic elements that serve the different
purposes in coming together to create this type of content?"
So an example, actually, to make it more concrete. If it's a blog post, your type is blog post.
Your elements would be title, author. You might have a teaser paragraph that you want
to break away from the rest of the body, because you may want to use that on its own somewhere.
So anything that you can see yourself wanting to separate out that is easy to divide from
the other elements should be its own building block.
Hannah: How does that look to the people who are actually writing and creating this content?
Bridget: That's a good question. It's going to depend based on how you implement this
technically. But generally speaking, I think what you'd be looking to do is customize whatever
content management system you're using in such a way that if the people writing it are
not technical at all, you give them little fields. They can enter it all in separately.
But behind that, what it will be doing is using markup, and there are sort of several
markup languages that you can use. The one that we, as SEOs, are probably most familiar
with would be Schema.org, but that is not all there is to markup. Simply put, markup
is simply a way of describing the content that you have. So on a title, it might be
a headline tag. It might be an author tag on your author byline. The reason you want
to do that, rather than just formatting it as a headline, you want to tag it as a headline,
because that way, when it goes out into the world, when it's being displayed across platforms
and shared across other sort of devices, that attribute of it being a headline will still
be there, even if your pretty formatting isn't.
Hannah: The simplest way is to maybe explain it as, like, rather than formatting your headline
by, like, making it 20 point, making it bold, maybe italic if you're that way inclined,
go crazy, instead of doing that, you're letting the CMS determine what size it should be dependent
on the device. You're just tagging it as a headline.
Bridget: Exactly. Yeah, that's exactly right. And that will help, as well, when it comes
time to rearrange it, because you'll have rules in place that say, "Oh, a headline is
important. It needs to go at the top."
Hannah: From an SEO perspective, what is it that we really need to do as SEOs? Because
a lot of this, it seems to me like it's a very technical solution, and I'm guessing
that, for the most part, at least, it won't necessarily be SEOs that are building these
systems. But what is it we need to care about? What is it that we need to be particularly
involved with in the process?
Bridget: As you say, we're not going to do the technical implementation ourselves. I
think it's more useful to think in terms of how it can help us do our job better, because
then we'll know what to focus on when we're in the stage of thinking about what's important.
Hannah: Do you have, like, a concrete example of that in the wild? So maybe a publisher
who has an awful lot of content, and they've maybe implemented something like content everywhere,
and it enabled them to create richer pages as a result?
Bridget: I think a great example of this is actually BBC Food, which has all sorts of
different groups of content. You might say they have pages about chefs, they have pages
about their food programs, they have pages with recipes. And what they've done is linked
it all up, because all of these different types of content actually share a common attribute,
and that's a dish. So they've ensured, by using this sort of method, that each of these
pieces of content includes that element of dish. And what that means is that when you
go to the BBC Food page and you click on any one of these things, you have this incredibly
rich resource.
You might think, well, that's great for user experience. Does it actually help with search?
Well, the results that they saw indicate it does, because after implementing this, they
saw 150,000 more visitors per week, just from search, and doubled their traffic overall.
Hannah: Beyond creating rich help pages, are there any other potential SEO benefits with
content everywhere?
Bridget: I think absolutely, because as we've mentioned, it's all about markup, and it's
all about structuring our data, and those are things that are very exciting for SEOs
because it basically does our job for us. What our job is, really, is to make sure that
web pages that we are working on are very clearly indicating what they do, and all this
is doing is taking that to a new level. We've seen already a bit of that with Schema.org,
for example, which we mentioned earlier. So what we can use this for, in a way, is doing
that work for us. Instead of implementing Schema.org on every single page, we can actually
just incorporate that when we're customizing our CMS, so that as the content creator is
putting the content into the editor of whatever kind, you can have content fields that map
onto the Schema.org attributes that you want to include in the page and set it up so that
it will generate that code for you. So I think that's very exciting.
Hannah: And I guess, really, just to wrap up, what would you like people to do next?
Like, what should people take away from this?
Bridget: I think, really, just go out and learn more about it, because it is a system.
It's not going to be your total strategy. But what it does do for us is enables us to
sort of scale up all of the content work that we're trying to do in a way that's future-proofing
it. So we're not just chasing after the latest device or the latest new platform, but actually
we can feel confident that our content will be ready no matter what comes out next, and
that's really important. So it might seem a bit intimidating or overwhelming, because
implementing the whole thing would be a lot of work. But what you should remember is you
don't have to do everything at once. You can start by implementing it on a few pages. You
can start by choosing a single type of content that you want to work on with. Any little
bit that you can do to get started with this will help you in the future.
Hannah: Definitely. Cool. Well, thanks so much for joining us. We'll see you soon.