DistilledLive | Dealing with Content Beyond the Webpage

DistilledLive | Dealing with Content Beyond the Webpage


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.

Author: Kevin Mason

Leave a Reply

Your email address will not be published. Required fields are marked *