Tangential Content Earns More Links and Social Shares in Boring Industries [New Research]

Posted by kerryjones

Many companies still don’t see the benefit of creating content that isn’t directly about their products or brand. But unless you have a universally interesting brand, you’ll be hard-pressed to attract much of an audience if all you do is publish brand-centric content.

Content marketing is meant to solve this dilemma. By offering genuinely useful content to your target customers, rather than selling to them, you earn their attention and over time gain their trust.

And yet, I find myself explaining the value of non-branded content all too often. I frequently hear grumblings from fellow marketers that clients and bosses refuse to stray from sales-focused content. I see companies publishing what are essentially advertorials and calling it content marketing.

In addition to turning off customers, branded content can be extremely challenging for building links or earning PR mentions. If you’ve ever done outreach for branded content, you’ve probably gotten a lot of pushback from the editors and writers you’ve pitched. Why? Most publishers bristle at content that feels like a brand endorsement pretending not to be a brand endorsement (and expect you to pay big bucks for a sponsored content or native advertising spot).

Fortunately, there’s a type of content that can earn your target customers’ attention, build high-quality links, and increase brand awareness...

Tangential content: The cure for a boring niche

At Fractl, we refer to content on a topic that’s related to (but not directly about) the brand that created it as "tangential content."

Some hypothetical examples of tangential content would be:

• A pool installation company creating content about summer safety tips and barbeque recipes.
• A luggage retailer publishing country-specific travel guides.
• An auto insurance broker offering car maintenance advice.

While there’s a time for branded content further down the sales funnel, tangential content might be right for you if you want to:

1. Reach a wide audience and gain top-of-funnel awareness. Not a lot of raving fans in your “boring” brand niche? Tangential topics can get you in front of the masses.
2. Target a greater number of publishers during outreach to increase your link building and PR mention potential. Tangential topics work well for outreach because you can expand your pool of publishers (larger niches vs. a small niche with only a few dedicated sites).
3. Create more emotional content that resonates with your audience. In an analysis of more than 300 client campaigns, we found the content that received more than 200 media mentions was more likely than low-performing campaigns to have a strong emotional hook. If your brand niche doesn’t naturally tug on the heartstrings, tangential content is one way to create an emotional reaction.
4. Build a more diverse content library and not be limited to creating content around one topic. If you’ve maxed out on publishing content about your niche, broadening your content repertoire to tangential topics can reinvigorate your content strategy (and your motivation).

Comparison of tangential vs. on-brand content performance

In our experience at Fractl, tangential content has been highly effective for link building campaigns, especially in narrow client niches that lack broad appeal. While we’ve assumed this is true based on our observations, we now have the data to back up our assumption.

We recently categorized 835 Fractl client campaigns as either “tangential” or “on-brand,” then compared the average number of pickups (links and press mentions) and number of social shares for each group. Our hunch was right: The tangential campaigns earned 30% more media mentions and 77% more social shares on average than the brand-focused campaigns.

So what exactly does a tangential campaign look like? Below are some real examples of our client campaigns that illustrate how tangential topics can yield stellar results.

Most Hateful/Most Politically Correct Places

• Client niche: Apartment listing site
• Campaign topic: Which states and cities use the most prejudiced/racist language based on geo-tagged Twitter data
• Results: 67,000+ social shares and 620 media pickups, including features on CNET, Slate, Business Insider, AOL, Yahoo, Mic, The Daily Beast, and Adweek

Why it worked

After a string of on-brand campaigns for this client yielded average results, we knew capitalizing on a hot-button, current issue would attract tons of attention. This topic still ties back into the client’s main objective of helping people find a home since the community and location of that home are important factors in one’s decisions. Check out the full case study of this campaign for more insights into why it was successful.

Most Instagrammed Locations

• Client niche: Bus fare comparison and booking tool
• Campaign topic: Points of interest where people post the most Instagram photos in North America
• Results: 40,000+ social shares and more than 300 pickups, including TIME, NBC News, Business Insider, Today, Yahoo!, AOL, Fast Company, and The Daily Mail

Why it worked

Our client’s niche, bus travel, had a limited audience, so we chose a topic that was of interest to anyone who enjoys traveling, regardless of the mode of transportation they use to get there. By incorporating data from a popular social network and using an idea with a strong geographic focus, we could target a lot of different groups — the campaign appealed to travel enthusiasts, Instagram users, and regional and city news outlets (including TV stations). For more details about our thought process behind this idea, see the campaign case study.

Most Attractive NFL Players and Teams

Client niche: Sports apparel retailer

Campaign topic: Survey that rates the most attractive NFL players

Results: 45,000+ social shares and 247 media pickups, including CBS Sports, USA Today, Fox Sports, and NFL.com

Why it worked

Since diehard fans want to show off that their favorite player is the best, even if it’s just in the looks department, we were confident this lighthearted campaign would pique fan interest. But fans weren’t the only ones hitting the share button — the campaign also grabbed the attention of the featured teams and players, with many sharing on their social media profiles, which helped drive exposure.

On-brand content works best in certain verticals

Tangential content isn’t always necessary for earning top-of-funnel awareness. So, how do you know if your brand-centric topics will garner lots of interest? A few things to consider:

• Is your brand topic interesting or useful to the general population?
• Are there multiple publishers that specifically cover your niche? Do these publishers have large readerships?
• Are you already publishing on-brand content that is achieving your goals/expectations?

We’ve seen several industry verticals perform very well using branded content. When we broke down our campaign data by vertical, we found our top performing on-brand campaign topics were technology, drugs and alcohol, and marketing.

Some examples of our successful on-brand campaign topics include:

• “Growth of SaaS” for a B2B software comparison website
• “Influencers on Instagram” for an influencer marketplace
• “Global Drug Treatment Trends” for an addiction recovery client
• “The Tech Job Network” for a tech career website

Coming up with tangential content ideas

Once you free yourself from only brainstorming brand-centric ideas, you might find it easy to dream up tangential concepts. If you need a little help, here are a few tips to get you started:

Review your buyer personas.

In order to know which tangential topics to choose, you need to understand your target audience’s interests and where your niche intersects with those interests. The best way to find this information? Buyer personas. If you don’t already have detailed buyer personas built out, Mike King’s epic Moz post from a few years ago remains the bible on personas in my opinion.

Find topics your audience cares about with Facebook Audience Insights.

Using its arsenal of user data, this Facebook ads tool gives you a peek into the interests and lifestyles of your target audience. These insights can supplement and inform your buyer personas. See the incredibly actionable post “How to Create Buyer Personas on a Budget Using Facebook Audience Insights” for more help with leveraging this tool.

Consider how trending news topics are tangential to your brand.

Pay attention to themes that keep popping up in the news and how your brand relates back to these stories (this is how the most racist/bigoted states and cities campaign I mentioned earlier in this post came to be). Also anticipate seasonal or event-based topics that are tangential to your brand. For example, a tire manufacturer may want to create content on protecting your car from flooding and storm damage during hurricane season.

Test tangential concepts on social media.

Not sure if a tangential topic will go over well? Before moving forward with a big content initiative, test it out by sharing content related to the topic on your brand’s social media accounts. Does it get a good reaction? Pro tip: spend a little bit of money promoting these as sponsored posts to ensure they get in front of your followers.

Have you had success creating content outside of your brand niche? I’d love to hear about your tangential content examples and the results you achieved, please share in the comments!

Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don't have time to hunt down but want to read!

http://ift.tt/2yNMjNC

NEW in Keyword Explorer: See Who Ranks & How Much with Keywords by Site

Posted by randfish

For many years now, Moz's customers and so, so many of my friends and colleagues in the SEO world have had one big feature request from our toolset: "GIVE ME KEYWORDS BY SITE!"

Today, we're answering that long-standing request with that precise data inside

Keyword Explorer:

This data is likely familiar to folks who've used tools like SEMRush, KeywordSpy, Spyfu, or others, and we have a few areas we think are stronger than these competitors, and a few known areas of weakness (I'll get to both in a minute). For those who aren't familiar with this type of data, it offers a few big, valuable solutions for marketers and SEOs of all kinds. You can:

1. Get a picture of how many (and which) keywords your site is currently ranking for, in which positions, even if you haven't been directly rank-tracking.
2. See which keywords your competitors rank for as well, giving you new potential keyword targets.
3. Run comparisons to see how many keywords any given set of websites share rankings for, or hold exclusively.
4. Discover new keyword opportunities at the intersection of your own site's rankings with others, or the intersection of multiple sites in your space.
5. Order keywords any site ranks for by volume, by ranking position, or by difficulty
6. Build lists or add to your keyword lists right from the chart showing a site's ranking keywords
7. Choose to see keywords by root domain (e.g. *.redfin.com including all subdomains), subdomain (e.g. just "www.redfin.com" or just "press.redfin.com"), or URL (e.g. just "http://ift.tt/2i73XFL")
8. Export any list of ranking keywords to a CSV, along with the columns of volume, difficulty, and ranking data

Find your keywords by site

My top favorite features in this new release are:

#1 - The clear, useful comparison data between sites or pages

Comparing the volume of a site's ranking keywords is a really powerful way to show how, even when there's a strong site in a space (like Sleepopolis in the mattress reviews world), they are often losing out in the mid-long tail of rankings, possibly because they haven't targeted the quantity of keywords that their competitors have.

This type of crystal-clear interface (powerful enough to be used by experts, but easily understandable to anyone) really impressed me when I saw it. Bravo to Moz's UI folks for nailing it.

#2 - The killer Venn diagram showing keyword overlaps

Aww yeah! I love this interactive venn diagram of the ranking keywords, and the ability to see the quantity of keywords for each intersection at a glance. I know I'll be including screenshots like this in a lot of the analyses I do for friends, startups, and non-profits I help with SEO.

#3 - The accuracy & recency of the ranking, volume, & difficulty data

As you'll see in the comparison below, Moz's keyword universe is technically smaller than some others. But I love the trustworthiness of the data in this tool. We refresh not only rankings, but keyword volume data multiple times every month (no dig on competitors, but when volume or rankings data is out of date, it's incredibly frustrating, and lessens the tool's value for me). That means I can use and rely on the metrics and the keyword list — when I go to verify manually, the numbers and the rankings match. That's huge.

Caveat: Any rankings that are personalized or geo-biased tend to have some ranking position changes or differences. If you're doing a lot of geographically sensitive rankings research, it's still best to use a rank tracking solution like the one in Moz Pro Campaigns (or, at an enterprise level, a tool like STAT).

---

How does Moz's keyword universe stack up to the competition? We're certainly the newest player in this particular space, but we have some advantages over the other players (and, to be fair, some drawbacks too). Moz's Russ Jones put together this data to help compare:

Click the image for a larger version

Obviously, we've made the decision to be generally smaller, but fresher, than most of our competitors. We do this because:

• A) We believe the most-trafficked keywords matter more when comparing the overlaps than getting too far into the long tail (this is particularly important because once you get into the longer tail of search demand, an unevenness in keyword representation is nearly unavoidable and can be very misleading)
• B) Accuracy matters a lot with these types of analyses, and keyword rankings data that's more than 3–4 weeks out of date can create false impressions. It's also very tough to do useful comparisons when some keyword rankings have been recently refreshed and others are weeks or months behind.
• C) We chose an evolving corpus that uses clickstream-fed data from Jumpshot to cycle in popular keywords and cycle out others that have lost popularity. In this fashion, we feel we can provide the truest, most representational form of the keyword universe being used by US searchers right now.

Over time, we hope to grow our corpus (so long as we can maintain accuracy and freshness, which provide the advantages above), and extend to other geographies as well.

If you're a Moz Pro subscriber and haven't tried out this feature yet, give it a spin. To explore keywords by site, simply enter a root domain, subdomain, or exact page into the universal search bar in Keyword Explorer. Use the drop if you need to modify your search (for example, researching a root domain as a keyword).

There's immense value to be had here, and a wealth of powerful, accurate, timely rankings data that can help boost your SEO targeting and competitive research efforts. I'm looking forward to your comments, questions, and feedback!

---

Need some extra guidance? Sign up for our upcoming webinar on either Thursday, October 26th or Monday, October 30th.

Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don't have time to hunt down but want to read!

http://ift.tt/2zwV2Rs

NEW in Keyword Explorer: See Who Ranks & How Much with Keywords by Site

Posted by randfish

For many years now, Moz's customers and so, so many of my friends and colleagues in the SEO world have had one big feature request from our toolset: "GIVE ME KEYWORDS BY SITE!"

Today, we're answering that long-standing request with that precise data inside

Keyword Explorer:

This data is likely familiar to folks who've used tools like SEMRush, KeywordSpy, Spyfu, or others, and we have a few areas we think are stronger than these competitors, and a few known areas of weakness (I'll get to both in a minute). For those who aren't familiar with this type of data, it offers a few big, valuable solutions for marketers and SEOs of all kinds. You can:

1. Get a picture of how many (and which) keywords your site is currently ranking for, in which positions, even if you haven't been directly rank-tracking.
2. See which keywords your competitors rank for as well, giving you new potential keyword targets.
3. Run comparisons to see how many keywords any given set of websites share rankings for, or hold exclusively.
4. Discover new keyword opportunities at the intersection of your own site's rankings with others, or the intersection of multiple sites in your space.
5. Order keywords any site ranks for by volume, by ranking position, or by difficulty
6. Build lists or add to your keyword lists right from the chart showing a site's ranking keywords
7. Choose to see keywords by root domain (e.g. *.redfin.com including all subdomains), subdomain (e.g. just "www.redfin.com" or just "press.redfin.com"), or URL (e.g. just "http://ift.tt/2i73XFL")
8. Export any list of ranking keywords to a CSV, along with the columns of volume, difficulty, and ranking data

Find your keywords by site

My top favorite features in this new release are:

#1 - The clear, useful comparison data between sites or pages

Comparing the volume of a site's ranking keywords is a really powerful way to show how, even when there's a strong site in a space (like Sleepopolis in the mattress reviews world), they are often losing out in the mid-long tail of rankings, possibly because they haven't targeted the quantity of keywords that their competitors have.

This type of crystal-clear interface (powerful enough to be used by experts, but easily understandable to anyone) really impressed me when I saw it. Bravo to Moz's UI folks for nailing it.

#2 - The killer Venn diagram showing keyword overlaps

Aww yeah! I love this interactive venn diagram of the ranking keywords, and the ability to see the quantity of keywords for each intersection at a glance. I know I'll be including screenshots like this in a lot of the analyses I do for friends, startups, and non-profits I help with SEO.

#3 - The accuracy & recency of the ranking, volume, & difficulty data

As you'll see in the comparison below, Moz's keyword universe is technically smaller than some others. But I love the trustworthiness of the data in this tool. We refresh not only rankings, but keyword volume data multiple times every month (no dig on competitors, but when volume or rankings data is out of date, it's incredibly frustrating, and lessens the tool's value for me). That means I can use and rely on the metrics and the keyword list — when I go to verify manually, the numbers and the rankings match. That's huge.

Caveat: Any rankings that are personalized or geo-biased tend to have some ranking position changes or differences. If you're doing a lot of geographically sensitive rankings research, it's still best to use a rank tracking solution like the one in Moz Pro Campaigns (or, at an enterprise level, a tool like STAT).

---

How does Moz's keyword universe stack up to the competition? We're certainly the newest player in this particular space, but we have some advantages over the other players (and, to be fair, some drawbacks too). Moz's Russ Jones put together this data to help compare:

Click the image for a larger version

Obviously, we've made the decision to be generally smaller, but fresher, than most of our competitors. We do this because:

• A) We believe the most-trafficked keywords matter more when comparing the overlaps than getting too far into the long tail (this is particularly important because once you get into the longer tail of search demand, an unevenness in keyword representation is nearly unavoidable and can be very misleading)
• B) Accuracy matters a lot with these types of analyses, and keyword rankings data that's more than 3–4 weeks out of date can create false impressions. It's also very tough to do useful comparisons when some keyword rankings have been recently refreshed and others are weeks or months behind.
• C) We chose an evolving corpus that uses clickstream-fed data from Jumpshot to cycle in popular keywords and cycle out others that have lost popularity. In this fashion, we feel we can provide the truest, most representational form of the keyword universe being used by US searchers right now.

Over time, we hope to grow our corpus (so long as we can maintain accuracy and freshness, which provide the advantages above), and extend to other geographies as well.

If you're a Moz Pro subscriber and haven't tried out this feature yet, give it a spin. To explore keywords by site, simply enter a root domain, subdomain, or exact page into the universal search bar in Keyword Explorer. Use the drop if you need to modify your search (for example, researching a root domain as a keyword).

There's immense value to be had here, and a wealth of powerful, accurate, timely rankings data that can help boost your SEO targeting and competitive research efforts. I'm looking forward to your comments, questions, and feedback!

---

Need some extra guidance? Sign up for our upcoming webinar on either Thursday, October 26th or Monday, October 30th.

Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don't have time to hunt down but want to read!

How Links in Headers, Footers, Content, and Navigation Can Impact SEO - Whiteboard Friday

Posted by randfish

Which link is more valuable: the one in your nav, or the one in the content of your page? Now, how about if one of those in-content links is an image, and one is text? Not all links are created equal, and getting familiar with the details will help you build a stronger linking structure.

Click on the whiteboard image above to open a high-resolution version in a new tab!

Video Transcription

Howdy, Moz fans, and welcome to another edition of Whiteboard Friday. This week we're going to chat about links in headers and footers, in navigation versus content, and how that can affect both internal and external links and the link equity and link value that they pass to your website or to another website if you're linking out to them.

So I'm going to use Candy Japan here. They recently crossed $1 million in sales. Very proud of Candy Japan. They sell these nice boxes of random assortments of Japanese candy that come to your house. Their website is actually remarkably simplistic. They have some footer links. They have some links in the content, but not a whole lot else. But I'm going to imagine them with a few more links in here just for our purposes.

It turns out that there are a number of interesting items when it comes to internal linking. So, for example, some on-page links matter more and carry more weight than other kinds. If you are smart and use these across your entire site, you can get some incremental or potentially some significant benefits depending on how you do it.

Do some on-page links matter more than others?

So, first off, good to know that...

I. Content links tend to matter more

...just broadly speaking, than navigation links. That shouldn't be too surprising, right? If I have a link down here in the content of the page pointing to my Choco Puffs or my Gummies page, that might actually carry more weight in Google's eyes than if I point to it in my navigation.

Now, this is not universally true, but observably, it seems to be the case. So when something is in the navigation, it's almost always universally in that navigation. When something is in here, it's often only specifically in here. So a little tough to tell cause and effect, but we can definitely see this when we get to external links. I'll talk about that in a sec.

II. Links in footers often get devalued

So if there's a link that you've got in your footer, but you don't have it in your primary navigation, whether that's on the side or the top, or in the content of the page, a link down here may not carry as much weight internally. In fact, sometimes it seems to carry almost no weight whatsoever other than just the indexing.

III. More used links may carry more weight

This is a theory for now. But we've seen some papers on this, and there has been some hypothesizing in the SEO community that essentially Google is watching as people browse the web, and they can get that data and sort of see that, hey, this is a well-trafficked page. It gets a lot of visits from this other page. This navigation actually seems to get used versus this other navigation, which doesn't seem to be used.

There are a lot of ways that Google might interpret that data or might collect it. It could be from the size of it or the CSS qualities. It could be from how it appears on the page visually. But regardless, that also seems to be the case.

IV. Most visible links may get more weight

This does seem to be something that's testable. So if you have very small fonts, very tiny links, they are not nearly as accessible or obvious to visitors. It seems to be the case that they also don't carry as much weight in Google's rankings.

V. On pages with multiple links to the same URL

For example, let's say I've got this products link up here at the top, but I also link to my products down here under Other Candies, etc. It turns out that Google will see both links. They both point to the same page in this case, both pointing to the same page over here, but this page will only inherit the value of the anchor text from the first link on the page, not both of them.

So Other Candies, etc., that anchor text will essentially be treated as though it doesn't exist. Google ignores multiple links to the same URL. This is actually true internal and external. For this reason, if you're going ahead and trying to stuff in links in your internal content to other pages, thinking that you can get better anchor text value, well look, if they're already in your navigation, you're not getting any additional value. Same case if they're up higher in the content. The second link to them is not carrying the anchor text value.

Can link location/type affect external link impact?

Other items to note on the external side of things and where they're placed on pages.

I. In-content links are going to be more valuable than footers or nav links

In general, nav links are going to do better than footers. But in content, this primary content area right in here, that is where you're going to get the most link value if you have the option of where you're going to get an external link from on a page.

II. What if you have links that open in a new tab or in a new window versus links that open in the same tab, same window?

It doesn't seem to matter at all. Google does not appear to carry any different weight from the experiments that we've seen and the ones we've conducted.

III. Text links do seem to perform better, get more weight than image links with alt attributes

They also seem to perform better than JavaScript links and other types of links, but critically important to know this, because many times what you will see is that a website will do something like this. They'll have an image. This image will be a link that will point off to a page, and then below it they'll have some sort of caption with keyword-rich anchors down here, and that will also point off. But Google will treat this first link as though it is the one, and it will be the alt attribute of this image that passes the anchor text, unless this is all one href tag, in which case you do get the benefit of the caption as the anchor. So best practice there.

IV. Multiple links from same page — only the first anchor counts

Well, just like with internal links, only the first anchor is going to count. So if I have two links from Candy Japan pointing to me, it's only the top one that Google sees first in the HTML. So it's not where it's organized in the site as it renders visually, but where it comes up in the HTML of the page as Google is rendering that.

V. The same link and anchor on many or most or all pages on a website tends to get you into trouble.

Not always, not universally. Sometimes it can be okay. Is Amazon allowed to link to Whole Foods from their footer? Yes, they are. They're part of the same company and group and that kind of thing. But if, for example, Amazon were to go crazy spamming and decided to make it "cheap avocados delivered to your home" and put that in the footer of all their pages and point that to the http://ift.tt/2yViyvr page, that would probably get penalized, or it may just be devalued. It might not rank at all, or it might not pass any link equity. So notable that in the cases where you have the option of, "Should I get a link on every page of a website? Well, gosh, that sounds like a good deal. I'd pass all this page rank and all this link equity." No, bad deal.

Instead, far better would be to get a link from a page that's already linked to by all of these pages, like, hey, if we can get a link from the About page or from the Products page or from the homepage, a link on the homepage, those are all great places to get links. I don't want a link on every page in the footer or on every page in a sidebar. That tends to get me in trouble, especially if it is anchor text-rich and clearly keyword targeted and trying to manipulate SEO.

All right, everyone. I look forward to your questions. We'll see you again next week for another edition of Whiteboard Friday. Take care.

Video transcription by Speechpad.com

Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don't have time to hunt down but want to read!

How Links in Headers, Footers, Content, and Navigation Can Impact SEO - Whiteboard Friday

Posted by randfish

Which link is more valuable: the one in your nav, or the one in the content of your page? Now, how about if one of those in-content links is an image, and one is text? Not all links are created equal, and getting familiar with the details will help you build a stronger linking structure.

Click on the whiteboard image above to open a high-resolution version in a new tab!

Video Transcription

Howdy, Moz fans, and welcome to another edition of Whiteboard Friday. This week we're going to chat about links in headers and footers, in navigation versus content, and how that can affect both internal and external links and the link equity and link value that they pass to your website or to another website if you're linking out to them.

So I'm going to use Candy Japan here. They recently crossed $1 million in sales. Very proud of Candy Japan. They sell these nice boxes of random assortments of Japanese candy that come to your house. Their website is actually remarkably simplistic. They have some footer links. They have some links in the content, but not a whole lot else. But I'm going to imagine them with a few more links in here just for our purposes.

It turns out that there are a number of interesting items when it comes to internal linking. So, for example, some on-page links matter more and carry more weight than other kinds. If you are smart and use these across your entire site, you can get some incremental or potentially some significant benefits depending on how you do it.

Do some on-page links matter more than others?

So, first off, good to know that...

I. Content links tend to matter more

...just broadly speaking, than navigation links. That shouldn't be too surprising, right? If I have a link down here in the content of the page pointing to my Choco Puffs or my Gummies page, that might actually carry more weight in Google's eyes than if I point to it in my navigation.

Now, this is not universally true, but observably, it seems to be the case. So when something is in the navigation, it's almost always universally in that navigation. When something is in here, it's often only specifically in here. So a little tough to tell cause and effect, but we can definitely see this when we get to external links. I'll talk about that in a sec.

II. Links in footers often get devalued

So if there's a link that you've got in your footer, but you don't have it in your primary navigation, whether that's on the side or the top, or in the content of the page, a link down here may not carry as much weight internally. In fact, sometimes it seems to carry almost no weight whatsoever other than just the indexing.

III. More used links may carry more weight

This is a theory for now. But we've seen some papers on this, and there has been some hypothesizing in the SEO community that essentially Google is watching as people browse the web, and they can get that data and sort of see that, hey, this is a well-trafficked page. It gets a lot of visits from this other page. This navigation actually seems to get used versus this other navigation, which doesn't seem to be used.

There are a lot of ways that Google might interpret that data or might collect it. It could be from the size of it or the CSS qualities. It could be from how it appears on the page visually. But regardless, that also seems to be the case.

IV. Most visible links may get more weight

This does seem to be something that's testable. So if you have very small fonts, very tiny links, they are not nearly as accessible or obvious to visitors. It seems to be the case that they also don't carry as much weight in Google's rankings.

V. On pages with multiple links to the same URL

For example, let's say I've got this products link up here at the top, but I also link to my products down here under Other Candies, etc. It turns out that Google will see both links. They both point to the same page in this case, both pointing to the same page over here, but this page will only inherit the value of the anchor text from the first link on the page, not both of them.

So Other Candies, etc., that anchor text will essentially be treated as though it doesn't exist. Google ignores multiple links to the same URL. This is actually true internal and external. For this reason, if you're going ahead and trying to stuff in links in your internal content to other pages, thinking that you can get better anchor text value, well look, if they're already in your navigation, you're not getting any additional value. Same case if they're up higher in the content. The second link to them is not carrying the anchor text value.

Can link location/type affect external link impact?

Other items to note on the external side of things and where they're placed on pages.

I. In-content links are going to be more valuable than footers or nav links

In general, nav links are going to do better than footers. But in content, this primary content area right in here, that is where you're going to get the most link value if you have the option of where you're going to get an external link from on a page.

II. What if you have links that open in a new tab or in a new window versus links that open in the same tab, same window?

It doesn't seem to matter at all. Google does not appear to carry any different weight from the experiments that we've seen and the ones we've conducted.

III. Text links do seem to perform better, get more weight than image links with alt attributes

They also seem to perform better than JavaScript links and other types of links, but critically important to know this, because many times what you will see is that a website will do something like this. They'll have an image. This image will be a link that will point off to a page, and then below it they'll have some sort of caption with keyword-rich anchors down here, and that will also point off. But Google will treat this first link as though it is the one, and it will be the alt attribute of this image that passes the anchor text, unless this is all one href tag, in which case you do get the benefit of the caption as the anchor. So best practice there.

IV. Multiple links from same page — only the first anchor counts

Well, just like with internal links, only the first anchor is going to count. So if I have two links from Candy Japan pointing to me, it's only the top one that Google sees first in the HTML. So it's not where it's organized in the site as it renders visually, but where it comes up in the HTML of the page as Google is rendering that.

V. The same link and anchor on many or most or all pages on a website tends to get you into trouble.

Not always, not universally. Sometimes it can be okay. Is Amazon allowed to link to Whole Foods from their footer? Yes, they are. They're part of the same company and group and that kind of thing. But if, for example, Amazon were to go crazy spamming and decided to make it "cheap avocados delivered to your home" and put that in the footer of all their pages and point that to the http://ift.tt/2yViyvr page, that would probably get penalized, or it may just be devalued. It might not rank at all, or it might not pass any link equity. So notable that in the cases where you have the option of, "Should I get a link on every page of a website? Well, gosh, that sounds like a good deal. I'd pass all this page rank and all this link equity." No, bad deal.

Instead, far better would be to get a link from a page that's already linked to by all of these pages, like, hey, if we can get a link from the About page or from the Products page or from the homepage, a link on the homepage, those are all great places to get links. I don't want a link on every page in the footer or on every page in a sidebar. That tends to get me in trouble, especially if it is anchor text-rich and clearly keyword targeted and trying to manipulate SEO.

All right, everyone. I look forward to your questions. We'll see you again next week for another edition of Whiteboard Friday. Take care.

Video transcription by Speechpad.com

Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don't have time to hunt down but want to read!

http://ift.tt/2yCCArp

Unlocking Hidden Gems Within Schema.org

Posted by alexis-sanders

Schema.org is cryptic. Or at least that’s what I had always thought. To me, it was a confusing source of information: missing the examples I needed, not explaining which item properties search engines require, and overall making the process of implementing structured data a daunting task. However, once I got past Schema.org’s intimidating shell, I found an incredibly useful and empowering tool. Once you know how to leverage it, Schema.org is an indispensable tool within your SEO toolbox.

A structured data toolbox

The first part of any journey is finding the map. In terms of structured data, there are a few different guiding resources:

• The most prominent and useful are Google’s Structured Data Features Guides. These guides are organized by the different structured data markups Google is explicitly using. Useful examples are provided with required item properties.
  
  Tip: If any of the item types listed in the feature guides are relevant to your site, ensure that you're annotating these elements.

• I also want to share Merkle’s new, free, supercalifragilisticexpialidocious Structured Data Markup Generator. It contains Google’s top markups with an incredibly user-friendly experience and all of the top item properties. This tool is a great support for starting your markups, and it’s great for individuals looking to reverse-engineer markups. It offers JSON-LD and some illustrative microdata markups. You can also send the generated markups directly to Google’s structured data testing tool.

• If you’re looking to go beyond Google’s recommendations and structure more data, check out Schema.org’s Full Hierarchy. This is a full list of all Schema.org’s core and extended vocabulary (i.e., a list of all item types). This page is very useful to determine additional opportunities for markup that may align with your structured data strategy.
  
  Tip: Click “Core plus all extensions” to see extended Schema.org’s libraries and what's in the pipeline.

• Last but not least is Google’s Structured Data Testing Tool. It is vital to check every markup with GSDTT for two reasons:
  • To avoid silly syntactic mistakes (don’t let commas be your worst enemy — there are way better enemies out there ☺).
  • Ensure all required item properties are included

As an example, I’m going to walk through the Aquarium item type Schema.org markup. For illustrative purposes, I’m going to stick with JSON-LD moving forward; however, if there are any microdata questions, please reach out in the comments.

Basic structure of all Schema.org pages

When you first enter a Schema.org item type’s page, notice that every page has the same layout, starting with the item type name, the canonical reference URL (currently the HTTP version*), where the markup lives within the Schema.org hierarchy, and that item type’s usage on the web.

*Leveraging the HTTPS version of a Schema.org markup is acceptable

What is an item type?

An item type is a piece of Schema.org’s vocabulary of data used to annotate and structure elements on a web page. You can think about it as what you’re marking up.

At the highest level of most Schema.org item types is Thing (alternatively, we’d be looking at DataType). This intuitively makes sense because almost everything is, at its highest level of abstraction, a Thing. The item type Thing has multiple children, all of which assume Thing’s properties in a cascading in a hierarchical fashion (i.e., a Product is a Thing, both can have names, descriptions, and images).

Explore Schema.org’s item types here with the various visualizations:

http://ift.tt/2x4th1P

Item types are going to be the first attribute in your markup and will look a little like this (remember this for a little later):

Tip: Every Schema.org item type can be found by typing its name after Schema.org, i.e. http://ift.tt/29ncxrU (note that case is important).

Below, this is where things start to get fun — the properties, expected type, and description of each property.

What are item properties?

Item properties are attributes, which describe item types (i.e., it’s a property of the item). All item properties are inherited from the parent item type. The value of the property can be a word, URL, or number.

What is the "Expected Type"?

For every item type, there is a column the defines the expected item type of each item property. This is a signal which tells us whether or not nesting will be involved. If the expected property is a data type (i.e., text, number, etc.) you will not have to do anything; otherwise get ready for some good, old-fashioned nesting.

One of the things you may have noticed: under “Property” it says “Properties from CivicStructure.” We know that an Aquarium is a child of CivicStructure, as it is listed above. If we scan the page, we see the following “Properties from…”:

This looks strikingly like the hierarchy listed above and it is (just vertical… and backward). Only one thing is missing – where are the “Properties from Aquarium”?

The answer is actually quite simple — Aquarium has no item properties of its own. Therefore, CivilStructures (being the next most specific item type with properties) is listed first.

Structuring this information with more specific properties at the top makes a ton of sense intuitively. When marking up information, we are typically interested in the most specific item properties, ones that are closest conceptually to the thing we’re marking up. These properties are generally the most relevant.

Creating a markup

1. Open the Schema.org item type page.
   • In this case, we’ll go to http://ift.tt/29ncxrU.
2. Review all item properties and select all relevant attributes.
   • After looking at the documentation, openingHours, address, aggregateRating, telephone, alternateName, description, image, name, and sameAs (social media linking item property) stood out as the most cogent and useful for aquarium goers. In an effort to map out all of the information, I added the “Expected Type” (which will be important in the next step) and the value of the information we’re going to markup.

   

3. Add the starting elements of all markup.
   • All markup, whether JSON-LD or microdata, starts with the same set of code/markup. One can memorize this code or leverage examples and copy/paste.
   • JSON-LD: Add the script tag with the JSON-LD type, along with the @context, and @type with the item type included:

   

4. Start light. Add the easier item properties (i.e., the ones that don’t require nesting).
   • First off, how do you tell whether or not the property nests?
     • This is where the “Expected Type” column comes into play.
     • If the “Expected Type” is “Text”, “URL”, or “Number” — you don’t need to nest.
   • I’ve highlighted the item properties that do not require nesting above in green. We’ll start by adding these to our markup.
   • JSON-LD: Contains the item property in quotation marks, along with the value (text and URLs are always in quotation marks). If there are multiple values, they’re listed as arrays within square [brackets].

   

5. Finish strong. Add the nested item properties.
   • Nested item properties are item types within item types. Through nesting, we can access the properties of the nested item type.
   • JSON-LD: Nested item properties start off like normal item properties; however, things get weird after the colon. A curly brace opens up a new world. We start by declaring a new item type and thus, inside these curly braces all item properties now belong to the new item type. Note how commas are not included after the last property.
   
6. Test in Google’s Structured Data Testing Tool.
   • Looks like we’re all good to go, with no errors and no warnings.

Side notes:

• *address: Google’s documentation list address, nested within PostAddress as a requirement. This is a good indicator of why it’s important to review Google’s documentation.
• openingHours: Multiple times are listed out in an array (as indicated by the square brackets). As the documentation’s “Description section” mentions – using a hyphen for ranges and military time.
  • Note: Google’s documentation uses the openingHoursSpecification item property, which nests OpeningHoursSpecification. This is a good example where Google documentation shows a more specific experience to consider.
• telephone: Sometimes you need to add a country code (+1) for phone numbers.
• image: URLs must be absolute (i.e., protocol and domain name included).

TL;DR:

• Schema.org’s documentation can be leveraged to supplement Google’s structured data documentation
• The “Expected Type” on Schema.org tells you when you need to nest an item type
• Check out Merkle’s Structured Data Markup Generator if you want to try simply inserting values and getting a preliminary markup

Thanks!

A huge thanks to Max Prin (@maxxeight), Adam Audette (@audette), and the @MerkleCRM team for reviewing this article. Plus, shout outs to Max (again), Steve Valenza (#TwitterlessSteve), and Eric Hammond (@elhammond) for their work, ideas, and thought leadership that went into the Schema Generator Tool!

Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don't have time to hunt down but want to read!

http://ift.tt/2kXGF6r

Unlocking Hidden Gems Within Schema.org

Posted by alexis-sanders

Schema.org is cryptic. Or at least that’s what I had always thought. To me, it was a confusing source of information: missing the examples I needed, not explaining which item properties search engines require, and overall making the process of implementing structured data a daunting task. However, once I got past Schema.org’s intimidating shell, I found an incredibly useful and empowering tool. Once you know how to leverage it, Schema.org is an indispensable tool within your SEO toolbox.

A structured data toolbox

The first part of any journey is finding the map. In terms of structured data, there are a few different guiding resources:

• The most prominent and useful are Google’s Structured Data Features Guides. These guides are organized by the different structured data markups Google is explicitly using. Useful examples are provided with required item properties.
  
  Tip: If any of the item types listed in the feature guides are relevant to your site, ensure that you're annotating these elements.

• I also want to share Merkle’s new, free, supercalifragilisticexpialidocious Structured Data Markup Generator. It contains Google’s top markups with an incredibly user-friendly experience and all of the top item properties. This tool is a great support for starting your markups, and it’s great for individuals looking to reverse-engineer markups. It offers JSON-LD and some illustrative microdata markups. You can also send the generated markups directly to Google’s structured data testing tool.

• If you’re looking to go beyond Google’s recommendations and structure more data, check out Schema.org’s Full Hierarchy. This is a full list of all Schema.org’s core and extended vocabulary (i.e., a list of all item types). This page is very useful to determine additional opportunities for markup that may align with your structured data strategy.
  
  Tip: Click “Core plus all extensions” to see extended Schema.org’s libraries and what's in the pipeline.

• Last but not least is Google’s Structured Data Testing Tool. It is vital to check every markup with GSDTT for two reasons:
  • To avoid silly syntactic mistakes (don’t let commas be your worst enemy — there are way better enemies out there ☺).
  • Ensure all required item properties are included

As an example, I’m going to walk through the Aquarium item type Schema.org markup. For illustrative purposes, I’m going to stick with JSON-LD moving forward; however, if there are any microdata questions, please reach out in the comments.

Basic structure of all Schema.org pages

When you first enter a Schema.org item type’s page, notice that every page has the same layout, starting with the item type name, the canonical reference URL (currently the HTTP version*), where the markup lives within the Schema.org hierarchy, and that item type’s usage on the web.

*Leveraging the HTTPS version of a Schema.org markup is acceptable

What is an item type?

An item type is a piece of Schema.org’s vocabulary of data used to annotate and structure elements on a web page. You can think about it as what you’re marking up.

At the highest level of most Schema.org item types is Thing (alternatively, we’d be looking at DataType). This intuitively makes sense because almost everything is, at its highest level of abstraction, a Thing. The item type Thing has multiple children, all of which assume Thing’s properties in a cascading in a hierarchical fashion (i.e., a Product is a Thing, both can have names, descriptions, and images).

Explore Schema.org’s item types here with the various visualizations:

http://ift.tt/2x4th1P

Item types are going to be the first attribute in your markup and will look a little like this (remember this for a little later):

Tip: Every Schema.org item type can be found by typing its name after Schema.org, i.e. http://ift.tt/29ncxrU (note that case is important).

Below, this is where things start to get fun — the properties, expected type, and description of each property.

What are item properties?

Item properties are attributes, which describe item types (i.e., it’s a property of the item). All item properties are inherited from the parent item type. The value of the property can be a word, URL, or number.

What is the "Expected Type"?

For every item type, there is a column the defines the expected item type of each item property. This is a signal which tells us whether or not nesting will be involved. If the expected property is a data type (i.e., text, number, etc.) you will not have to do anything; otherwise get ready for some good, old-fashioned nesting.

One of the things you may have noticed: under “Property” it says “Properties from CivicStructure.” We know that an Aquarium is a child of CivicStructure, as it is listed above. If we scan the page, we see the following “Properties from…”:

This looks strikingly like the hierarchy listed above and it is (just vertical… and backward). Only one thing is missing – where are the “Properties from Aquarium”?

The answer is actually quite simple — Aquarium has no item properties of its own. Therefore, CivilStructures (being the next most specific item type with properties) is listed first.

Structuring this information with more specific properties at the top makes a ton of sense intuitively. When marking up information, we are typically interested in the most specific item properties, ones that are closest conceptually to the thing we’re marking up. These properties are generally the most relevant.

Creating a markup

1. Open the Schema.org item type page.
   • In this case, we’ll go to http://ift.tt/29ncxrU.
2. Review all item properties and select all relevant attributes.
   • After looking at the documentation, openingHours, address, aggregateRating, telephone, alternateName, description, image, name, and sameAs (social media linking item property) stood out as the most cogent and useful for aquarium goers. In an effort to map out all of the information, I added the “Expected Type” (which will be important in the next step) and the value of the information we’re going to markup.

   

3. Add the starting elements of all markup.
   • All markup, whether JSON-LD or microdata, starts with the same set of code/markup. One can memorize this code or leverage examples and copy/paste.
   • JSON-LD: Add the script tag with the JSON-LD type, along with the @context, and @type with the item type included:

   

4. Start light. Add the easier item properties (i.e., the ones that don’t require nesting).
   • First off, how do you tell whether or not the property nests?
     • This is where the “Expected Type” column comes into play.
     • If the “Expected Type” is “Text”, “URL”, or “Number” — you don’t need to nest.
   • I’ve highlighted the item properties that do not require nesting above in green. We’ll start by adding these to our markup.
   • JSON-LD: Contains the item property in quotation marks, along with the value (text and URLs are always in quotation marks). If there are multiple values, they’re listed as arrays within square [brackets].

   

5. Finish strong. Add the nested item properties.
   • Nested item properties are item types within item types. Through nesting, we can access the properties of the nested item type.
   • JSON-LD: Nested item properties start off like normal item properties; however, things get weird after the colon. A curly brace opens up a new world. We start by declaring a new item type and thus, inside these curly braces all item properties now belong to the new item type. Note how commas are not included after the last property.
   
6. Test in Google’s Structured Data Testing Tool.
   • Looks like we’re all good to go, with no errors and no warnings.

Side notes:

• *address: Google’s documentation list address, nested within PostAddress as a requirement. This is a good indicator of why it’s important to review Google’s documentation.
• openingHours: Multiple times are listed out in an array (as indicated by the square brackets). As the documentation’s “Description section” mentions – using a hyphen for ranges and military time.
  • Note: Google’s documentation uses the openingHoursSpecification item property, which nests OpeningHoursSpecification. This is a good example where Google documentation shows a more specific experience to consider.
• telephone: Sometimes you need to add a country code (+1) for phone numbers.
• image: URLs must be absolute (i.e., protocol and domain name included).

TL;DR:

• Schema.org’s documentation can be leveraged to supplement Google’s structured data documentation
• The “Expected Type” on Schema.org tells you when you need to nest an item type
• Check out Merkle’s Structured Data Markup Generator if you want to try simply inserting values and getting a preliminary markup

Thanks!

A huge thanks to Max Prin (@maxxeight), Adam Audette (@audette), and the @MerkleCRM team for reviewing this article. Plus, shout outs to Max (again), Steve Valenza (#TwitterlessSteve), and Eric Hammond (@elhammond) for their work, ideas, and thought leadership that went into the Schema Generator Tool!

Sign up for The Moz Top 10, a semimonthly mailer updating you on the top ten hottest pieces of SEO news, tips, and rad links uncovered by the Moz team. Think of it as your exclusive digest of stuff you don't have time to hunt down but want to read!