Do you have a recipe site? If so, you might already be using structured data to mark up your recipes so they can get highlighted in the search results. Good work! But, Google recently made some changes that might make your implementation incomplete. It also expanded the possibilities of structured data for recipes by bringing guidance into the mix. The result? Google Home can now read your structured data powered recipes out loud!

Want rich snippets for your site? Try our Structured data training »

Structured data training Info

Structured data, recipes and Google Home

Google is betting big on voice search. While voice search is still in its infancy, there are signs that we are moving towards a future where we are relying much less on our screens. There are many instances where talking to your digital assistant makes much more sense than typing commands. What’s more, the AI in digital assistants will become smarter and more apt at entering into a natural dialogue with you. We’re talking about a real natural language interface here.

A lot is going on right now. Take for instance that Google Duplex demo, showing a digital assistant calling a hairdresser to make an appointment. Joost wrote a post about Google Duplex and the ethics and implications. If AI is this smart, we need to take note.

To get voice search and actions to work, Google relies on structured data. Structured data makes it immediately clear what all the different parts of a page mean so search engines can use that to do cool stuff with. Google Actions, the big database featuring things you can let Assistant do, uses structured data. For instance, here is Google’s page on recipe actions — which is the same as the regular structured data for recipes documentation. If you want to learn all about structured data, please read our Ultimate Guide to Structured Data.

New rules, new results

Earlier this month, Google announced a new and improved way of targeting people who search for recipes. By adding the correct structured data, you can get your recipes read out load. Google even said that by implementing this you might: “receive traffic from more sources, since users can now discover your recipes through the Google Assistant on Google Home.”

But, when throwing random recipes from some of the largest recipe sites in the world into the Structured Data Testing Tool, you’ll find that hardly any fully comply with these new rules yet. What’s more, even the implementation of the recipe Schema.org itself is widely different between sites. That being said, there’s still a lot to win, even for the big boys.

As of now, Google recommends four new properties in addition to the ones you probably already use:

  • keywords: additional terms to describe the recipe
  • recipeCategory: in which category does the recipe fit?
  • recipeCuisine: from which region is the recipe?
  • video: use this if you have a video showing to make the recipe

You’ll see the recommendations in Google’s Structured Data Testing Tool:warnings structured data testing tool

Guidance: reading it out loud

How cool would it be if your Google Home could assist while you were cooking? Not by setting timers and the like, but by reading the recipe for you. That’s now possible thanks to guidance. In addition to the four new recommended properties for structured data for recipes, Google states that:

“To enable your recipe for guidance with the Google Home and Google Assistant, make sure you add recipeIngredient and recipeInstructions. If your recipe doesn’t have these properties, the recipe isn’t eligible for guidance, but may still be eligible to appear in Search results.”

To get your Google Home to pronounce the steps of your recipes correctly, you need to set the value of recipeInstructions using HowToStep or HowToSection. The latter, of course, should be used if your recipe instructions consist of multiple parts or sections. You can also keep everything in one block of recipeInstruction, but then you are at the mercy of Google as it has to try and work everything out itself. If you have distinct steps, please use HowToStep and/or HowToSection.

Hello keywords, we meet again

In a move straight out of 1997, we see keywords pop up again. Google now recommends using the keyword property to add context for your recipes. Now, this shouldn’t be confused with the recipeCategory and recipeCuisine properties. It is an extra way of describing your articles using words that don’t relate to a category or type of cuisine. We’ll just have to wait and see if the spammers can keep themselves under control.

Getting into that carousel

One of the coolest ways to discover content is the swipeable carousel you see when you search for certain types of content on mobile. To greaten the chance of your site appearing in this overview you can add an ItemList with one or more ListItems to your content.

Now, Google is quick to add that it might not be necessary to add this if you only want to appear in the regular search carousel. If you throw several well-known recipes sites into the Structured Data Testing Tool you will see that hardly any have added ItemList to their pages. Still, they rank high and appear in the carousel. If, however, you want to have site-specific entries — like your list of 5 best chocolate cheesecake recipes, or another type of landing page with recipes — into that carousel you need to add the ItemList structured data. There are several ways of doing this; you can find out more on Google’s documentation pages.

Applying structured data for recipes

If you look at Schema.org/Recipe, you might be starting to go a little bit green around the gills. Where do you even start? It’s massive! These are all the properties you could add, but that doesn’t mean that you should. Google requires just a couple but recommends a lot more.

These are the required properties:

  • @context: set to Schema.org
  • @type: set to Recipe
  • image: can be a URL or a ImageObject
  • name: name of the dish

That’s it! But, as you might have guessed, this won’t get you very far. By providing Google with as much data about your recipe as possible, you increase the chance that Google ‘gets’ your recipe. After that, it can apply the rich results and corresponding Actions accordingly.

Here are the recommended properties:

  • aggregateRating: average review score for this recipe
  • author: who made it? Use Schema.org/Person
  • cookTime: the time it takes to cook the recipe
  • datePublished: when was the recipe published?
  • description: a description of the recipe
  • keywords: terms to describe the recipe
  • nutrition.calories: the number of calories. Use Schema.org/Energy
  • prepTime: how long do the preparations take?
  • recipeCategory: is it breakfast, lunch, dinner or something else?
  • recipeCuisine: where in the world is the recipe from originally?
  • recipeIngredient: every ingredient you need to make the recipe. This property is required if you want Google Home to read your recipe out loud.
  • recipeInstructions: mark up the steps with HowToStep or HowToSection with embedded ItemistElement with a HowToStep.
  • recipeYield: for how many servings is this?
  • review: add any review you might have
  • totalTime: how long does it all take?
  • video: add a video showing how to make the recipe, if applicable

To show you how this all translates to code, we need an example. So, here’s Googles example recipe in JSON-LD format. You’ll see that it is all obvious and pretty easy to understand. If you want to implement JSON-LD code on your page, Google Tag Manager might be your best bet.

<!doctype html>
<html amp lang="en">
  <head>
    <meta charset="utf-8">
    <title>Party Coffee Cake</title>
    <link rel="canonical" href="http://example.ampproject.org/recipe-metadata.html" />
    <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">
    <script type="application/ld+json">
     {
      "@context": "http://schema.org/",
      "@type": "Recipe",
      "name": "Party Coffee Cake",
      "image": [
        "https://example.com/photos/1x1/photo.jpg",
        "https://example.com/photos/4x3/photo.jpg",
        "https://example.com/photos/16x9/photo.jpg"
        ],
      "author": {
        "@type": "Person",
        "name": "Mary Stone"
      },
      "datePublished": "2018-03-10",
      "description": "This coffee cake is awesome and perfect for parties.",
      "prepTime": "PT20M",
      "cookTime": "PT30M",
      "totalTime": "PT50M",
      "keywords": "cake for a party, coffee",
      "recipeYield": "10 servings",
      "recipeCategory": "Dessert",
      "recipeCuisine": "American",
      "nutrition": {
        "@type": "NutritionInformation",
        "calories": "270 calories"
         },
      "recipeIngredient": [
        "2 cups of flour",
        "3/4 cup white sugar",
        "2 teaspoons baking powder",
        "1/2 teaspoon salt",
        "1/2 cup butter",
        "2 eggs",
        "3/4 cup milk"
       ],
      "recipeInstructions": [
          {
          "@type": "HowToStep",
          "text": "Preheat the oven to 350 degrees F. Grease and flour a 9x9 inch pan."
          },
          {
          "@type": "HowToStep",
          "text": "In a large bowl, combine flour, sugar, baking powder, and salt."
          },
          {
          "@type": "HowToStep",
          "text": "Mix in the butter, eggs, and milk."
          },
          {
          "@type": "HowToStep",
          "text": "Spread into the prepared pan."
          },
          {
          "@type": "HowToStep",
          "text": "Bake for 30 to 35 minutes, or until firm."
          },
          {
          "@type": "HowToStep",
          "text": "Allow to cool."
         }
      ],
      "review": {
        "@type": "Review",
        "reviewRating": {
          "@type": "Rating",
          "ratingValue": "4",
          "bestRating": "5"
        },
        "author": {
          "@type": "Person",
          "name": "Julia Benson"
        },
        "datePublished": "2018-05-01",
        "reviewBody": "This cake is delicious!",
        "publisher": "The cake makery"
        },
      "aggregateRating": {
      "@type": "AggregateRating",
        "ratingValue": "5",
        "ratingCount": "18"
  },
  "video": [
     {
    "name": "How to make a Party Coffee Cake",
    "description": "This is how you make a Party Coffee Cake.",
    "thumbnailUrl": [
      "https://example.com/photos/1x1/photo.jpg",
      "https://example.com/photos/4x3/photo.jpg",
      "https://example.com/photos/16x9/photo.jpg"
     ],
    "contentUrl": "http://www.example.com/video123.flv",
    "embedUrl": "http://www.example.com/videoplayer.swf?video=123",
    "uploadDate": "2018-02-05T08:00:00+08:00",
    "duration": "PT1M33S",
    "interactionCount": "2347",
    "expires": "2019-02-05T08:00:00+08:00"
   }
  ]
}
</script>
  </head>
  <body>
    <h1>The best coffee cake you’ll ever try!</h1>
  </body>
</html>

Conclusion: Got a recipe site? Add structured data now!

Recipe sites are in a very cool position. It seems that they get everything first. By marking up your recipes with structured data, you can get Google to do a lot of cool stuff with your recipes. You can get them to pronounce it via Google Home or try to find other ways of interacting with them with Actions via the Assistant database. And this is probably only the beginning.

Read more: ‘Structured data: the ultimate guide’ »

The post Structured data for recipes: getting content read out loud appeared first on Yoast.

Perhaps you heard about Google Duplex? You know, the artificial assistant that called a hairdresser to make an appointment? Fascinating technology, but what is it exactly? And does it affect search or SEO? In this post, I’ll explain what Google Duplex is. And, I’ll raise some ethical issues I have with it. Finally, I will go into the consequences of Google Duplex for SEO.

What is Google Duplex?

Google Duplex is an experimental new technology that Google demoed at Google I/O, the company’s annual developer conference. This technology allows Google to mimic human conversation. Google is quick to say that at this point, it’s only trained for specific fields.

Free course! Learn what makes your site rank with our SEO for beginners training »

Free SEO course: SEO for beginners Info

Google showed a video in which a robot makes an appointment for a hairdressers appointment by calling that hairdresser and having an actual conversation. If you haven’t seen a demo of it yet, check out this video first.

Is it good?

Last Wednesday at the Google I/O conference, John Hennessy said about Google Duplex: “In the domain of making appointments, it passes the Turing test.” The Turing test is a test that determines whether a human is indistinguishable from a robot. This means that the robot used in Google Duplex is not distinguishable from an actual human being.

John Hennessy is the chairman of the board of Google’s parent company Alphabet. He is also quite a hero in the field of computer science. When he says something like that — even about his own company — it’s worth thinking about.

John Hennessy was pretty quick to point out that it passes in only one specific field: the task of booking appointments. “It doesn’t pass it in general terms, but it passes in that specific domain. And that’s really an indication of what’s coming.” Which gets us to ethics.

The ethics of AI that’s this good

When you have an Artificial Intelligence (AI) that can interact with people, as Google Duplex can, you need to think about ethics. Luckily, people have been thinking about precisely these kinds of ethics problems for a long time. The first set of rules you’ll run into when you search around ethics concerning AI are Isaac Asimov’s famous three laws of robotics, introduced in his 1942 (!) short story Runaround:

  1. A robot may not injure a human being or, through inaction, allow a human being to come to harm.
  2. A robot must obey the orders given it by human beings except where such orders would conflict with the First Law.
  3. A robot must protect its own existence as long as such protection does not conflict with the First or Second Laws.

While this laid the groundwork for almost all of the science fiction around robots, most of that doesn’t necessarily immediately come into play now. But since then, people have started adding on the three laws of robotics. The most well-known “fourth law of robotics” was added by novelist Lyuben Dilov, in his book Icarus’s Way. This law is as follows:

A robot must establish its identity as a robot in all cases.

Now, go back to the video linked above. Nowhere does that assistant state it’s a bot. In fact, it has mannerisms that make it very human. I think that’s wrong and I think people were rightly calling Google out on that. Google has already stated that they will change that. I’m curious how exactly. Let’s say I am skeptical. Google does not always communicate their intentions clearly. I mean: Google says it discloses which results are ads in its search results and which results aren’t. However, most ‘non-tech’ people don’t know what exactly is an ad and what is an organic result.  We’ll have to wait and see, or maybe, hear.

Security implications

In the wrong hands, this type of technology is incredibly scary. Did you know that it now takes less than 1 minute of recorded audio to reasonably accurately simulate somebody’s voice? Combine that with the inferior systems of security we currently have for phone conversations with, for instance, banks, and you have a potential disaster on your hands.

What will Google Duplex be used for?

The examples we’ve seen so far indicate that Google Duplex can be used to make straightforward phone calls – to plan meetings and make reservations. These examples fit the personal assistant purpose for which Google Assistant is promoted. But if an AI becomes this good at consumer interaction, of course, businesses will want to use it to receive phone calls as well. They could use it for helpdesks and other types of calls that we now task entire call centers with.

Future use of Google Duplex?

It is hard to say when Google Duplex will be used on a large scale. This might not happen next year or even the year after. But it’s definitely going faster than most people outside of the tech bubble realize. If Google Duplex can be trained to make a restaurant booking, it can also be trained to take your new credit card application. And, since it is an AI, it would be much faster and less error-prone than a human would be at performing your credit check.

Look at a Google Duplex-like system for receiving calls as a nice extension to the phone call conversion tracking system Google already has. Google could indeed take your credit card application. Or, without even all that much training, do the other side of the second example call in the video above and take the entire reservation system for a restaurant and automate it. The question then becomes: what if your digital assistant calls into the Duplex powered system on the other side? Will they use human-like conversation to get the job done? Will we end up with human speech as the ultimate computer to computer language?

Want rich snippets for your site? Try our Structured data training »

Structured data training Info

How does this impact search and SEO?

Google Duplex might not seem to have a direct impact on search, but consider this: if your Google Assistant can have conversations like this with your hairdresser and your restaurant of choice, will you have these conversations with him/her too? Suddenly you can talk to your phone and sound like you’re talking to your secretary, instead of sounding like the freak who talks to his phone or watch. Search becomes even more conversational and queries get more complicated.

When queries get more complicated, context becomes more important than ever. And now we’re back to what we’ve been writing about for quite a while here at Yoast: you need to write awesome content. I really can’t add much to what Marieke wrote in that post, so read it.

The other side of how this impacts SEO is more technical. For AIs to be efficient, it’s far easier to rely on structured data. If you use a standards-based system like Schema.org for things like reservations, all Google has to do is tie into that. Suddenly, it doesn’t have to retrain its system for a new booking engine; it can just detect that you use Schema.org for that, and poof, it just works.

Next steps

So what’s next? Well, now we wait. We wait until we get to play with this. We’ll have to figure out how good this truly is before we can do anything else.

Read more: ‘Readability ranks!’ »

The post Google Duplex: The what, the ethics, the SEO appeared first on Yoast.

There are many occassions when you may want to put a PDF on your site. For example, when you’ve made an online magazine, when an article you wrote was featured in a book or magazine, or when you’ve written detailed instructions for a DIY project. So far, so good.

But things can get a bit more complicated when you also have the content from this PDF somewhere else on your site, or on another website. To avoid duplicate content, you need to set a canonical URL. But how do you do that for a PDF document? And what is the best way to do that? Let’s discuss in today’s Ask Yoast!

Karen Schousboe emailed us her question:

I plan to publish a PDF magazine under medieval.news. Some of the articles in each issue will also be freely available on a sister website. How should I handle that? Do I link canonical from the articles to the PDF magazine or from the magazine to the website?”

Watch the video or read the transcript further down the page for my answer!

Canonicalization and PDFs

“Well, you can have a canonical HTTP header and what I would suggest doing is canonicalizing from the PDF magazine to the sister website, because HTML pages just rank a lot better than PDFs, usually.

In fact, I would suggest publishing everything in HTML and not necessarily in PDF because PDF is just not very easy to land on from search. You can’t do any tracking, you can’t do a whole lot of things that you can do with HTML. So I would seriously consider doing all of it in HTML pages and then canonicalizing between them. Good luck.”

Become a technical SEO expert with our Technical SEO 1 training! »

Technical SEO 1 training Info

Ask Yoast

In the series Ask Yoast, we answer SEO questions from our readers. Have an SEO-related question? Maybe we can help you out! Send an email to ask@yoast.com.

Note: please check our blog and knowledge base first, the answer to your question may already be out there! For urgent questions, for example about our plugin not working properly, we’d like to refer you to our support page.

Read more: ‘rel=canonical: the ultimate guide’ »

The post Ask Yoast: Canonical for PDF magazine appeared first on Yoast.

Optimizing how your content looks when it’s shared on third-party platforms like Facebook, Twitter or WhatsApp can drive improved visibility, clickthrough, and conversions. But it’s not as simple as just picking a great image…

When you share a URL on Facebook, Twitter, or other platforms, they’ll typically show a preview of the page, with a title, description, and image. These elements are typically taken from Open Graph tags defined in the source code of the page you’re sharing.

How does this work?

The way in which this works is defined by the Open Graph Protocol. This is an open source standard (like WordPress, and even the Yoast SEO plugin), which allows webmasters to tell third-party systems (like Facebook, Twitter, Pinterest, or even WhatsApp, Skype or Hotmail) about their pages.

Star Wars

It defines a set of meta tags which allow you to provide information about the type of content on a page (e.g., “this is a page about a movie”), metadata about that thing (e.g., “it’s called Star Wars – The Last Jedi”), and how it should be presented when shared.

They look like something this:

<meta property="og:title" content="Star Wars - The Last Jedi" />
<meta property="og:type" content="video.movie" />
<meta property="og:url" content="https://www.imdb.com/title/tt2527336/" />
<meta property="og:image" content="https://ia.media-imdb.com/images/M/MV5BMjQ1MzcxNjg4N15BMl5BanBnXkFtZTgwNzgwMjY4MzI@._V1_SY1000_CR0,0,675,1000_AL_.jpg" />
<meta property="og:image:width" content="675" />
<meta property="og:image:height" content="1000" />

Most websites (and those running the Yoast SEO plugin) will automatically output elements like these for all pages, posts and archives.

The og:image tags are particularly important because Open Graph tags most commonly play a role in social sharing dialogues. This tag defines the picture which shows up when users share your content across social networks, apps, and other systems. Optimizing the composition, dimensions, and even the file size of the image you use can influence whether somebody clicks and the quality of their experience.

Using images which are too large, too small, or the wrong dimensions can result in errors, or in platforms omitting your images entirely. But optimizing your Open Graph markup isn’t as simple as just picking a good image. There are some complexities around how different platforms use these tags, treat your images, and support different rules.

TL;DR

  • It’s impossible to specify different images/formats/files for different networks, other than for Facebook and Twitter. The Facebook image is used, by default, for all other networks/systems). This is a limitation of how these platforms work. The same goes for titles and descriptions.
  • The Yoast SEO plugin will automatically try and specify the best image for each platform where you share your content, based on the constraints of these platforms.
  • The image size and cropping won’t always be perfect across different platforms, as the way in which they work is inconsistent.
  • Specifically, your images should look great on ‘broadcast’ platforms like Facebook and Twitter, but might sometimes crop awkwardly on platforms designed for 1:1 or small group conversations, like WhatsApp or Telegram.
  • For best results, you should manually specify og:image tags for each post, through the plugin. You should ensure that your primary og:image is between 1200x800px and 2000x1600px, and is less than 2mb in size.
  • We’ll be adding developer support for more advanced customization via theme functions and filters. 

    Optimize your site for search & social media and keep it optimized with Yoast SEO Premium »

    Yoast SEO: the #1 WordPress SEO plugin Info

It’s not as simple as just picking a good image

Even though Open Graph tags use an open standard, each platform (Facebook, Twitter, WhatsApp, etc) treats Open Graph tags slightly differently. Some even have their own proprietary ‘versions’ of Open Graph tagging, too. Twitter’s ‘twitter card’ markup, for example, bears a strong resemblance to, and overlaps with, Open Graph tagging.

As an open project, the Open Graph is constantly changing and improving, too. Features and support come and go, the documentation isn’t always up to date, and individual platforms make (and change) their own decisions on how they interpret it, and which bits they’ll implement.

And as the web itself continues to evolve, there are more and more ‘platforms’ where people can share content, and where the Open Graph is used. From Slack, to WeChat, to tomorrow’s productivity and social media apps, they’ll all rely on the Open Graph, but use it in subtly different ways.

So when we’re trying to define a ‘best practice’ approach to support as part of the Yoast SEO plugin, it’s not as simple as just picking the ‘best image’ – we need to make sure that we provide the right tags and image formats for each platform and network.

To make things more complex, these tags and approaches sometimes conflict with or override each other. Twitter’s twitter:image property, for example, overrides an og:image value for images shared via Twitter, when both sets of tags are on the same page.

Lastly, the open graph specification allows us to provide multiple og:image values. This, in theory, allows the platform to make the best decision about which size to use and allows people who are sharing some choice over which image they pick. How different platforms interpret these values, however, varies considerably.

This logic behind which platforms use which images, in which scenarios, gets complex pretty quickly! So more often than not, we’re stuck relying on the og:image value(s) as a general default for all platforms, and adding specific support where we can, whilst trying to minimize conflict. This doesn’t always produce perfect results, so we’re always on the lookout for better ways to ‘get it right’ without requiring end users to spend hours specifying multiple image formats for each post they write.

The challenge of og:image as a default

In a perfect world, there are two different approaches to how platforms handle Open Graph tagging. They look like this:

  1. All platforms only use og:image tags. When multiple images are set, they automatically select (and crop) the best version for their context.
  2. All platforms have specific Open Graph tags (or their own versions). They allow fine-grain control over every scenario, by enabling us to specify the exact image which should be used in each case.

Unfortunately, we’re stuck somewhere in-between. Some platforms allow a degree of control, but the og:image tag functions as a general fallback for all other scenarios.

FB plugin Yoast SEO

This is particularly problematic, as the og:image is also Facebook’s primary image. This is a huge challenge for the Yoast SEO plugin team, and for anybody else trying to define a ‘best practice’ approach to tagging. The image we specify as the main image for Facebook sharing (usually a large, high-res picture) also has to be suitable as a general default for all platforms which don’t have their own specific tags.

For many of these platforms, a large file size optimized for sharing in a Facebook newsfeed won’t be appropriate for their context. For example, Pinterest expects a relatively small, square cropped thumbnail image when sharing from a page – and whilst it has its own tagging mechanisms, the presence of an og:image tag on the page overrides those.

There’s more complexity, too. Different platforms have varying restrictions on image dimensions, ratios, and file size. A high-res og:image optimized for Facebook (with a large file size) will, more often than not, not display at all when someone shares it on Slack, for example.

Frequently, Yoast SEO has to share the same default og:image between multiple platforms – even though they have different expectations and apply different rules and treatments. Trying to work out what the ‘default’ image tag(s) should be, when it has to be the main image for Facebook and a universal default, is tricky. But it’s a problem we need to solve if we’re to provide a best practice ‘default’ setting for WordPress users.

There are lots of unknowns

Because each platform maintains its own rules and documentation on how they treat og:image tags, there are often gaps in our knowledge. Specific restrictions, edge cases, and in particular, information on which rules override other rules, are rarely well-documented. The documentation which does exist is often ambiguous at best. Google+ “snippet” documentation, for example, states that they won’t use images which are “not square enough”. It’s unclear what this means in specific, technical terms. HTML overview

In order to determine the best universal approach to image sharing markup, we had to do some digging and some experimentation.

We were particularly interested in understanding how different platforms react to the presence of multiple og:image tags. If we can specify more than one image, and different platforms handle that differently, perhaps there’s a way in which we can get them to pick the most suitable image for their needs.

What we found

The way in which different platforms handle og:image tags (and in particular, multiple og:image tags) is often inconsistent, and frequently complex. Thankfully, most small platforms and apps simply crop and use the og:image tag (or the first og:image tag, if there are multiple in the set), and apply some reasonable constraints around dimensions, ratio, and file size. Some of the larger and more popular platforms, however, exhibit some particularly challenging behaviors, which complicate matters.

Here are some examples of the undocumented behaviors we’ve discovered (note that we’ve not talked about platforms which simply pick the first og:image tag, and which don’t exhibit any other ‘odd’ behavior). If you find any other undocumented features or behaviors which we haven’t covered or supported (or if we’ve made any mistakes in our research), we’d love to hear from you!

Facebook

When multiple og:image tags are specified, Facebook uses the first tag in the set. This is in line with their documentation, but contrary to popular opinion (which assumes that the largest valid image is chosen). It’s also interesting to note that it uses the first image even if it’s invalid/brokenSelection FB

Additional images are available for selection by the user at the point of sharing (on desktop only). Images are hard-cropped and sized to fit the sharing dialogue window, based on the size of the window.

Instagram

Instagram behaves similarly to Facebook, except that it will only show an image preview for ‘small’ images (if the image file size is smaller than 300KB, and the dimensions are ~256×256 – though we’ve seen up to 400×400 work), and only supports JPG and PNG formats.

Twitter

Twitter uses the last image in an og:image set, unless a twitter:image tag exists. Using the twitter:image tag allows us to control Twitter images independently of all other types, though unfortunately doesn’t allow us to specify multiple values (to accommodate for different tweet contexts/layouts).

National Geographic

To add some complexity, Twitter supports multiple card layouts, which can be defined in a twitter:card tag. The default value is ‘summary’ (1:1 ratio), but it’s also possible to specify ‘summary_large_image’ for a larger, full-width image (2:1) ratio.

Unhelpfully, Twitter’s documentation shows the same layout for both card versions (summary, summary with large image).

Interestingly, Twitter used to support a ‘gallery’ type of card which held multiple images – however, they deprecated this into the ‘summary with large image’ card some time ago.

WhatsApp

WhatsApp also uses the last image in the og:image set, which it hard crops to a small square. Note that, this appears to accept enormous images, both in terms of file size and dimensions; this red square is cropped from a 10000×10000, 1.49mb image. Test page Jono

Skype

Takes the first og:image, but caches it seemingly permanently (both locally and in the cloud), making it impossible to change/update an image thumbnail for a URL (without, e.g., manipulating the og:url value to include cache-busting elements).

Telegram

Takes values from Facebook’s cache (typically the first og:image in a set). Cached images can be updated by messaging https://telegram.me/webpagebot (as a Telegram user) with up to 10 URLs. Note, caches only be updated if a page’s <html> tag contains a prefix=”og: http://ogp.me/ns#” attribute.

Pinterest

Pinterest’s documentation mentions that they “support” up to six og:image tags. However, sharing the page only ever utilizes the first* image the in the set.

They also support marking up inline images through Schema.org markup – however, when an og:image tag is present on the page (which will almost always be the case), it uses this instead.

Article Forbes

There’s also some ambiguity around the difference between how they handle Open Graph data with ‘article pins’ vs ‘rich pins’. The latter is an ‘upgraded’ version which displays more information on the card, but using these requires the site owner to validate their domain.

*There’s an edge-case where, if there are more than six images in the array, the sharing dialogue periodically seems to choose the seventh value (and there’s some other weirdness depending on the total numbers of images in the array).

Google+

Google’s Web Fundamentals documentation implies that Google+ may prefer (and will prioritize) schema markup over Open Graph markup. Theoretically, that might allow us to enable allow users to set a specific image for Google+. They also do some of the smartest intelligent cropping and ratio management (or, at least, the documentation on their approach is more complete and transparent than others).

As an interesting aside, Google+ ignores robots.txt directives, and so may unwittingly expose private/hidden assets.

What we’ve considered, and our decisions

That’s a lot of moving parts. We need to compare all of these rules and decide which og:image tags we output for any given post or page, on any given WordPress site running the Yoast SEO plugin. That means optimizing for the most common and general use-cases, without breaking too many edge-cases. It also means providing tools, hooks, and filters in WordPress to allow users with special requirements to alter the behavior to meet their particular needs.

That’s why we’re choosing to optimize the first image in the og:set for large, high-resolution sharing – the kind which Facebook supports and requires, but which cause issues with networks which expect a smaller image (like Instagram, or Telegram) sharing.

Whilst you could argue that Facebook might not necessarily wield the influence and domination that it used to, it’s undoubtedly still a significant platform in terms of audience size, and a place where page/post sharing is prolific – and where the quality/treatment of the image is critical to click through.

Given that both Facebook, and most platforms’ default is the first og:image tag in a set, we must ensure that this image is a large, high-quality image (with a suitable aspect ratio for Facebook). Unfortunately, this approach has some side-effects. There’ll be many cases where the image used is too large for Instagram (and other platforms which expect small thumbnails) to feature in shared post links.

We’re not completely happy with this as a solution, but it’s the best compromise we can come up with. As an aside, we also believe that, in its current state, Open Graph markup is a bit broken. We think that it feels intuitively right that the first and default og:image in a set should be a high quality, high-resolution image – and that it’s the responsibility of the platform to crop this down appropriately, or to use secondary/smaller og:images, or to provide their own markup/solutions.

Ideally, Open Graph tags would inherit some of the kinds of thinking behind CSS media queries, where you can specify the different screen widths at which different sets of logic apply. We’ll be seeking to lobby and work with the various platforms to improve their support and collaboration in the coming months and years.

User context is an important factor

We also think that this compromise makes more sense than optimizing for smaller images, because the context in which smaller thumbnails are used is different.

Example share link

We believe that individuals sharing URLs in one-to-one chat, or in small groups (e.g., in WhatsApp), are less likely to be negatively affected by a missing (or awkwardly sized/cropped) image. They’re usually chatting, engaged, and know the sender.

In the context of a newsfeed, like on Facebook or Twitter, the quality of the image is much more important – you’re scrolling through lots of noise, you’re less engaged, and a better image is an increased chance of a click/share/like. Structured data FB

In the case of Pinterest, and other systems where your interest is the image itself, we believe that most interaction occurs directly on the image, rather than from the page it’s on or a browser bookmarklet. Given this, we’re less concerned about Pinterest using the first og:image tag (which is a large image, optimized for Facebook) as a small, square thumbnail.

There’s an upper size limit, too

The biggest image you can have (both in terms of file size and dimensions) varies by platform, too. Some platforms support huge images (Facebook allows images to be up to 8mb) – but they chop these down into smaller thumbnails depending on the context. Some have relatively small max sizes, like LinkedIn and Telegram’s 2mb limit.

This makes it even more challenging to determine what the ‘best’ image should be, and which images should feature in the og:image set. We want to show a large, high-resolution image, but not too large.

It’s particularly tricky to pick the best size with WordPress, where we’re not always sure what image sizes we’ll be working with. That’s because, when a user uploads an image to WordPress, their site creates multiple versions of that image with different sizes and cropping. Typically, these are the original ‘full’ size, and ‘large’ (1024x1024px), ‘medium_large’ (768px, cropped), ‘medium’ (300x300px) and ‘thumbnail’ (150x150px) versions. But these default sizes are often altered by WordPress theme or plugin code, and by server configuration – and frequently, some might be too large for general use.

Because we need to make sure that the first og:image is suitable as a general default for as many platforms as possible, the Yoast SEO plugin evaluates post content, spots all of the images, and tries to pick the best size for each post. To get this right, we’ve evaluated the maximum file sizes and dimensions of a number of platforms, and we’ve set some automatic restrictions in the plugin.

Specifically:

  • When the ‘full’ size image is over 2mb file size, and/or over 2000 pixels on either axis, and/or the ratio exceeds 3:1, we’ll try and fall back to a smaller standard WordPress image size.
  • If we can’t find a suitable smaller image, we’ll continue to use the ‘full’ size. Note that this may result in the image not appearing in some sharing contexts.

In conclusion…

We don’t want our users to have to micromanage the details of how all of this works. Of course, when you’re producing great content for your audience, you should consider how that content appears on third party and social platforms. But it should be as simple a matter of picking an appropriate image, and letting the system do the rest – from sizing and file management, to ensuring that the best version shows up when it’s shared in other locations. Because every platform follows its own rules, however, we’ve had to make some decisions which won’t please every user and won’t solve for every scenario.

For most normal use-cases, we’d suggest that you manually set og:image values on your posts via the Yoast SEO plugin, and ensure that their dimensions are between 1200x800px and 2000x1600px (and that they’re less than 2mb in size).

If you disagree with the decisions we’ve made, or want to help us improve our solution; we’d love for you to get in touch. WordPress and Yoast SEO are both open source products – you can help by explaining your use-cases, reporting your bugs, and thinking about how a better solution might work.

We’d love to hear your thoughts; the Open Graph is a mess at the moment, and it’s up to all of us to fix it.

Some additional technical details

We’ve taken some liberty in the og:image markup, and we’re aware that we’re adding quite a lot of weight and markup with this approach. Specifically, we’ll output HTML which looks something like this:

<meta property="og:image" content="https://www.example.com/main-image.jpg" />
<meta property="og:image:secure_url" content="https://www.example.com/main-image.jpg" />
<meta property="og:image:height" content="2000" />
<meta property="og:image:width" content="2000" />
<meta property="og:image:alt" content="A description of the image" />
<meta property="og:image:type" content="image/jpg" />
<meta property="og:image" content="https://www.example.com/second-image.jpg" />
<meta property="og:image:secure_url" content="https://www.example.com/second-image.jpg" />
<meta property="og:image:height" content="800" />
<meta property="og:image:width" content="800" />
<meta property="og:image:alt" content="A description of the image" />
<meta property="og:image:type" content="image/jpg" />
<meta property="og:image" content="https://www.example.com/third-image.jpg" />
<meta property="og:image:secure_url" content="https://www.example.com/third-image.jpg" />
<meta property="og:image:height" content="600" />
<meta property="og:image:width" content="400" />
<meta property="og:image:alt" content="A description of the image" />
<meta property="og:image:type" content="image/jpg" />
<meta property="og:image" content="https://www.example.com/fourth-image.jpg" />
<meta property="og:image:secure_url" content="https://www.example.com/fourth-image.jpg" />
<meta property="og:image:height" content="256" />
<meta property="og:image:width" content="256" />
<meta property="og:image:alt" content="A description of the image" />
<meta property="og:image:type" content="image/jpg" />

Note the progression ‘down’ from ‘large, high-quality image’, through different media sizes (depending on the site/theme setup), ending at a universal ‘small’ size.

We’ll also output a twitter:image tag, alongside the other twitter:card requirements (unless you’ve chosen to disable it in the Yoast SEO plugin config).

We’ll likely continue to iterate and improve on the approach, but here’s our rationale behind some of our assumptions:

  • The og:image:type may not be strictly necessary in all cases, but there are many websites and server configurations where the images don’t have clean and recognizable ‘.jpg’ (or similar) file extensions. By making sure that we signpost the type of file, rather than making networks work it out, we reduce the risk of errors.
  • Facebook’s documentation around how it uses secure_url tags is unclear, especially for sites which are fully HTTPS. However, in the case of video tags, it mentions explicitly that both tags are required, even if both feature the same HTTPS URL. As such, we’ll retain the secure_url tags even when your site and image are served over HTTPS.
  • It’s generally considered best practice to label images with descriptive alt attributes, in order to support users who rely on screen readers and assistive technologies. We believe that Open Graph image tags shouldn’t be any different. This tag is only output when your images are labeled, so we’d encourage you to write some descriptive text during your image upload workflow.
  • Our 2mb file size limit aligns, incidentally, to the default upload size set in most WordPress implementations which run on ‘off the shelf’ hosting.
  • Our 2000×2000 pixel size flag should be a suitable maximum for almost all websites and screen sizes. Most browsers on desktop monitors have a width of fewer than 2,000 pixels (4k monitors and upwards often use image scaling to prevent everything from looking tiny). It’s also rare for any sharing ‘thumbnail’ activity (e.g., a Facebook message preview box) to take up the full width of the screen.
  • As Google+ isn’t widely used, we’ve chosen not to add additional complexity to the Yoast SEO plugin by offering the ability to specify dedicated, schema-based image markup for Google+ images. In most cases, we believe that the default og:image should be a suitable option for Google+ sharing – though we’re keen to hear from you if you find that this is not the case.
  • Unlike most other networks, WhatsApp supports SVG file formats. That means that, in theory, you could achieve optimal sharing for both WhatsApp and Facebook by setting your first og:image to be an SVG, and setting your second og:image as your full-res, large image. However. many other networks only read the first image, and won’t use the SVG file. SVG formats also come with a myriad of security risks, and so we’re not comfortable recommending their general use in this context.

Some undocumented Facebook ‘features’

If you’re feeling particularly geeky, you might also enjoy the following discoveries!

  • In addition to specifying the URL of an image, you can specify its height and width. This has some benefits, including encouraging Facebook to pre-cache the image on the first time it’s shared. However, when you specify multiple og:image tags, invalid/malformed height/width in any of those tags may cause problems with all of your images. E.g., an invalid og:image:height or og:image:width value on an image which isn’t chosen, prevents pre-rendering.
  • Specifying an image triggers the pre-caching process, regardless of whether it’s correct or not.
  • Facebook has different ‘share layout’ sizes, depending on the image size. Small images don’t scale up to a large preview very well, so they provide a condensed layout. However, the share layout size sometimes defaults to accommodating the smallest image from a set (e.g., if you have 10 huge og:image tags, and 1 small one, you sometimes get the small share layout).
  • Facebook also sometimes falls back to the ‘small’ layout if you have too many broken images in your set (as Facebook’s broken image file is only 540×300).
    Test page Jono
  • Setting incorrect image sizes lets you upscale small images in the Facebook debugger, but it doesn’t look like this is respected in the share dialogue. You cannot ‘downscale’ images so far as I can tell. There’s a “upscale=1” parameter in the version of the image which Facebook creates, which I suspect controls this.
  • Large images break! The maximum square image size appears to be in the region of 9200×9200. However, some images with unequal dimensions larger than this, but a lower total area (e.g., 10000×3000) work, as long as a 3:1 ratio or higher. Image test page JonoThis suggests that the boundaries might be based, in part, on a maximum square area of ~95,000,000 pixels.
  • As a minor additional note, when sharing a too-large image directly (i.e., linking directly to the file itself), Facebook just shows a blank image – there’s no fallback file/function used in their ‘safe image’ cleaner in this context.
  • Facebook supports a really interesting feature which lets you build relationships between pages featuring partial/linked Open Graph information. This, theoretically, allows you to ‘inherit’ and/or place centralized og markup elsewhere, reducing page weight. This might be useful for mobile/responsive subdomains, and some internationalization/versioning scenarios, perhaps, if other platforms supported it.
  • Additionally, where cloaking is often a risky tactic in SEO (and frowned upon by Google), Facebook actively suggest (see “You can target one of these user agents to serve the crawler a nonpublic version of your page”) cloaking mechanisms as a method of managing scenarios with paywalls, struggling servers, and other scenarios.
  • Despite claiming otherwise on their documentation, like Google+, Facebook’s crawler appears to ignore or disregard robots.txt directives – it’ll happily fetch Open Graph values from pages which are blocked by robots.txt files.

Some potential “hacks”?

Being stuck having to ‘share’ the first og:image tag between multiple networks is, as we’re discovering, limiting, and not ideal. Sticking to the Open Graph standards, as they’re written, lumps us with all sorts of unfortunate compromises and dead-ends.

So what if we think outside the rules a bit?

If we’re creative, there may be some clever tricks or undocumented approaches which we can use to bypass, confuse, or force certain behaviors from some of the trickier platforms.

Here are a few approaches we’ve considered, but ultimately discarded.

Can we use platform detection to create a dynamic solution?

Imagine for a moment, that every time a page is shared, the platform visits that page, reads the og:image tag(s), and grabs the image.

Theoretically, the Yoast SEO plugin could detect which platform is requesting the page or image, and execute some clever code to serve it the perfect image for its requirements.

That’d enable us to ensure that, regardless of what’s being shared, and where, we could intelligently make sure that the first og:image is the best option for the scenario.

However, the platforms don’t visit every time – they visit once, and save a copy of the tags (and the images) they found for a little while. That length of time, and the scenarios which cause them to revisit and/or update their cached version vary wildly by platform.

Still, theoretically, the Yoast SEO plugin could try and serve the right tags to the platform when they do visit, at the moment when they create their cache. But this approach relies heavily on the platforms identifying themselves when they visit (and on us recognizing their identities), on the website in question having a certain type of server configuration, and on our software doing some tricksy logic around deciding which tag(s) to show.

It might also open things up to forms of abuse by users and platforms who falsify their identities, and it won’t work for any website running any form of advanced caching (where the static pages are served to most visitors).

It all gets pretty complicated, and it’s not a robust enough approach to rely on.

Hidden image techniques

Some platforms, like Pinterest, do more than just grab the og:image tag(s) – they scan the page and look for other images too. That means that we can place sharing-optimized images outside of the Open Graph tags, as part of the page content, and hope that users select these when sharing.

In most scenarios, those images don’t necessarily need to be visible, in order to be discovered. We can place hidden images in the source code of a page.

Unfortunately, this technique doesn’t help in most cases, other than increasing the chance of an image showing up in a selection process. e.g., where Facebook allows you to select a thumbnail from an og:image set, or where Pinterest allows you to choose an image to share from a page when using their browser bookmarklet).

In most scenarios, in-page images are ignored when og:image tags are specified. Hiding images can also cause unexpected side-effects, such as accessibility issues, or slower page loads – especially when sharing the kinds of large images which platforms like Pinterest or Facebook look for in cases like this.

Publish-and-switch techniques

For some platforms, like Facebook, we can ‘push’ a specific image to them, by setting the first og:image and sending a request to their cache-busting URL.

We could adapt the Yoast SEO plugin to set a specific image as the first in the set, then ping the relevant platform’s cache-busting system to update the image. Then we could change the og:image ordering and repeat the process, setting the best image for each platform which allows for remote cache updating

Unfortunately, this only allows us to set the initial image. When their caches expire, we’re back to square one – they’ll use the logic we’ve outlined to pick their preferred images.

To repeat the cache-setting process, we’d need to constantly juggle the order of the tags, in line with the specific cache-expiry times of each platform. This adds a wealth of complexity, and simply isn’t feasible in most site setups (especially those running their own caching solutions), and only a few platforms support this kind of cache-busting.

More importantly, we want to avoid tactical hacks

As we’ve explored, we’re not keen on going to these kinds of lengths to try and fix a problem which could be fixed so much more effectively, and comprehensively, by the platforms themselves, and improvements to the Open Graph protocol.

We’re not adverse to implementing clever, technical solutions to help get the image selection process right, but we’d rather work with the platforms to address the problems at the source, rather than tackling the symptoms across the 8 million+ websites running the Yoast SEO plugin.

We’d love to hear your thoughts on how you think WordPress, Yoast SEO, the Open Graph Protocol and big platforms like Facebook and Twitter might be able to work together better!

Read on: ‘Social media optimization with Yoast SEO’ »

The post Advanced Technical SEO: How social image sharing works and how to optimize your og:image tags appeared first on Yoast.

Search engines like Google have a problem. It’s called ‘duplicate content.’ Duplicate content means that similar content is being shown on multiple locations (URLs) on the web. As a result, search engines don’t know which URL to show in the search results. This can hurt the ranking of a webpage. Especially when people start linking to all the different versions of the content, the problem becomes bigger. This article will help you to understand the various causes of duplicate content, and to find the solution for each of them.

What is duplicate content?

You can compare duplicate content to being on a crossroad. Road signs are pointing in two different directions for the same final destination: which road should you take? And now, to make it ‘worse’ the final destination is different too, but only ever so slightly. As a reader, you don’t mind: you get the content you came for. A search engine has to pick which one to show in the search results. It, of course, doesn’t want to show the same content twice.

Let’s say your article about ‘keyword x’ appears on http://www.example.com/keyword-x/ and the same content also appears on http://www.example.com/article-category/keyword-x/. This situation is not fictitious: it happens in lots of modern Content Management Systems. Your article has been picked up by several bloggers. Some of them link to the first URL; others link to the second URL. This is when the search engine’s problem shows its real nature: it’s your problem. The duplicate content is your problem because those links are both promoting different URLs. If they were all linking to the same URL, your chance of ranking for ‘keyword x’ would be higher.

Learn how to write awesome and SEO friendly articles in our SEO Copywriting training »

SEO copywriting training Info

Table of contents

1 Causes for duplicate content

There are dozens of reasons that cause duplicate content. Most of them are technical: it’s not very often that a human decides to put the same content in two different places without distinguishing the source: it feels unnatural to most of us. The technical reasons are plentiful though. It happens mostly because developers don’t think as a browser or a user, let alone a search engine spider, they think as a developer. That aforementioned article, that appears on http://www.example.com/keyword-x/ and http://www.example.com/article-category/keyword-x/? If you ask the developer, he’ll say it only exists once.

1.1 Misunderstanding the concept of a URL

Has that developer gone mad? No, he’s just speaking a different language. You see a database system probably powers the whole website. In that database, there’s only one article, the website’s software just allows for that same article in the database to be retrieved through several URLs. That’s because, in the eyes of the developer, the unique identifier for that article is the ID that article has in the database, not the URL. For the search engine though, the URL is the unique identifier to a piece of content. If you explain that to a developer, he’ll start getting the problem. And after reading this article, you’ll even be able to provide him with a solution right away.

1.2 Session IDs

You often want to keep track of your visitors and make it possible, for instance, to store items they want to buy in a shopping cart. To do that, you need to give them a ‘session.’ A session is a brief history of what the visitor did on your site and can contain things like the items in their shopping cart. To maintain that session as a visitor clicks from one page to another, the unique identifier for that session, the so-called Session ID, needs to be stored somewhere. The most common solution is to do that with cookies. However, search engines usually don’t store cookies.

At that point, some systems fall back to using Session IDs in the URL. This means that every internal link on the website gets that Session ID appended to the URL, and because that Session ID is unique to that session, it creates a new URL, and thus duplicate content.

1.3 URL parameters used for tracking and sorting

Another cause for duplicate content is the use of URL parameters that do not change the content of a page, for instance in tracking links. You see, http://www.example.com/keyword-x/ and http://www.example.com/keyword-x/?source=rss are not the same URL for a search engine. The latter might allow you to track what source people came from, but it might also make it harder for you to rank well. A very unwanted side effect!

This doesn’t just go for tracking parameters, of course. It goes for every parameter you can add to a URL that doesn’t change the vital piece of content, whether that parameter is for ‘changing the sorting on a set of products’ or for ‘showing another sidebar’: they all cause duplicate content.

1.4 Scrapers & content syndication

Most of the causes for duplicate content are all your own or at the very least your website’s ‘fault.’ Sometimes, however, other websites use your content, with or without your consent. They do not always link to your original article, and thus the search engine doesn’t ‘get’ it and has to deal with yet another version of the same article. The more popular your site becomes, the more scrapers you’ll often have, making this issue bigger and bigger.

1.5 Order of parameters

Optimize your site for search & social media and keep it optimized with Yoast SEO Premium »

Yoast SEO: the #1 WordPress SEO plugin Info
Another common cause is that a CMS doesn’t use nice and clean URLs, but rather URLs like /?id=1&cat=2, where ID refers to the article and cat refers to the category. The URL /?cat=2&id=1 will render the same results in most website systems, but they’re completely different for a search engine.

1.6 Comment pagination

In my beloved WordPress, but also in some other systems, there is an option to paginate your comments. This leads to the content being duplicated across the article URL, and the article URL + /comment-page-1/, /comment-page-2/ etc.

If your content management system creates printer friendly pages and you link to those from your article pages, in most cases Google will find those, unless you specifically block them. Now, which version should Google show? The one laden with ads and peripheral content,  or the one with just your article?

1.8 WWW vs. non-WWW

One of the oldest in the book, but sometimes search engines still get it wrong: WWW vs. non-WWW duplicate content, when both versions of your site are accessible. A less common situation but one I’ve seen as well: HTTP vs. HTTPS duplicate content, where the same content is served out over both.

2 Conceptual solution: a ‘canonical’ URL

As determined above, the fact that several URLs lead to the same content is a problem, but it can be solved. A human working at a publication will normally be able to tell you quite easily what the ‘correct’ URL for a certain article should be. The funny thing is, though, sometimes when you ask three people in the same company, they’ll give three different answers…

That’s a problem that needs solving in those cases because, in the end, there can be only one (URL). That ‘correct’ URL for a piece of content has been dubbed the Canonical URL by the search engines.

canonical_graphic_1024x630

Ironic side note

Canonical is a term stemming from the Roman Catholic tradition, where a list of sacred books was created and accepted as genuine. They were dubbed the canonical Gospels of the New Testament. The irony is: it took the Roman Catholic church about 300 years and numerous fights to come up with that canonical list, and they eventually chose four versions of the same story

3 Identifying duplicate contents issues

You might not know whether you have a duplicate content issue on your site or with your content. Let me give you some methods of finding out whether you do.

3.1 Google Search Console

Google Search Console is a great tool for identifying duplicate content. If you go into the Search Console for your site, check under Search Appearance » HTML Improvements, and you’ll see this:

If pages have duplicate titles or duplicate descriptions, that’s almost never a good thing. Clicking on it will reveal the URLs that have duplicate titles or descriptions and will help you identify the problem. The issue is that if you have an article like the one about keyword X, and it shows up in two categories, the titles might be different. They might, for instance, be ‘Keyword X – Category X – Example Site’ and ‘Keyword X – Category Y – Example Site’. Google won’t pick those up as duplicate titles, but you can find them by searching.

3.2 Searching for titles or snippets

There are several search operators that are very helpful for cases like these. If you’d want to find all the URLs on your site that contain your keyword X article, you’d type the following search phrase into Google:

site:example.com intitle:"Keyword X"

Google will then show you all pages on example.com that contain that keyword. The more specific you make that intitle part, the easier it is to weed out duplicate content. You can use the same method to identify duplicate content across the web. Let’s say the full title of your article was ‘Keyword X – why it is awesome’, you’d search for:

intitle:"Keyword X - why it is awesome"

And Google would give you all sites that match that title. Sometimes it’s worth even searching for one or two complete sentences from your article, as some scrapers might change the title. In some cases, when you do a search like that, Google might show a notice like this on the last page of results:

Duplicate content noticed by Google

This is a sign that Google is already ‘de-duping’ the results. It’s still not good, so it’s worth clicking the link and looking at all the other results to see whether you can fix some of those.

4 Practical solutions for duplicate content

Once you’ve decided which URL is the canonical URL for your piece of content, you have to start a process of canonicalization (yeah I know, try to say that three times out loud fast). This means we have to let the search engine know about the canonical version of a page and let it find it ASAP. There are four methods of solving the problem, in order of preference:

  1. Not creating duplicate content
  2. Redirecting duplicate content to the canonical URL
  3. Adding a canonical link element to the duplicate page
  4. Adding an HTML link from the duplicate page to the canonical page

4.1 Avoiding duplicate content

Some of the above causes for duplicate content have very simple fixes to them:

  • Session ID’s in your URLs?
    These can often just be disabled in your system’s settings.
  • Have duplicate printer friendly pages?
    These are completely unnecessary: you should just use a print style sheet.
  • Using comment pagination in WordPress?
    You should just disable this feature  (under settings » discussion) on 99% of sites.
  • Parameters in a different order?
    Tell your programmer to build a script to always order parameters in the same order (this is often referred to as a so-called URL factory).
  • Tracking links issues?
    In most cases, you can use hash tag based campaign tracking instead of parameter-based campaign tracking.
  • WWW vs. non-WWW issues?
    Pick one and stick with it by redirecting the one to the other. You can also set a preference in Google Webmaster Tools, but you’ll have to claim both versions of the domain name.

If you can’t fix your problem that easily, it might still be worth it to put in the effort. The goal would be to prevent the duplicate content from appearing altogether. It’s by far the best solution to the problem.

4.2 301 Redirecting duplicate content

In some cases, it’s impossible to entirely prevent the system you’re using from creating wrong URLs for content, but sometimes it is possible to redirect them. If this isn’t logical to you (which I can understand), do keep it in mind while talking to your developers. If you do get rid of some of the duplicate content issues, make sure that you redirect all the old duplicate content URLs to the proper canonical URLs. 

Learn how to write awesome and SEO friendly articles in our SEO Copywriting training »

SEO copywriting training Info

4.3 Using rel=”canonical” links

Sometimes you don’t want to or can’t get rid of a duplicate version of an article, even when you do know that it’s the wrong URL. For that particular issue, the search engines have introduced the canonical link element. It’s placed in the section of your site, and it looks like this:

<link rel="canonical" href="http://example.com/wordpress/seo-plugin/">

In the href section of the canonical link, you place the correct canonical URL for your article. When a search engine that supports canonical finds this link element, it performs what is a soft 301 redirect. It transfers most of the link value gathered by that page to your canonical page.

This process is a bit slower than the 301 redirect though, so if you can do a 301 redirect that would be preferable, as mentioned by Google’s John Mueller.

Read more: ‘ rel=canonical • What it is and how (not) to use it ’ »

4.4 Linking back to the original content

If you can’t do any of the above, possibly because you don’t control thesection of the site your content appears on, adding a link back to the original article on top of or below the article is always a good idea. This might be something you want to do in your RSS feed: add a link back to the article in it. Some scrapers will filter that link out, but some others might leave it in. If Google encounters several links pointing to your article, it will figure out soon enough that that’s the actual canonical version of the article.

5 Conclusion: duplicate content is fixable, and should be fixed

Duplicate content happens everywhere. I have yet to encounter a site of more than 1,000 pages that hasn’t got at least a tiny duplicate content problem. It’s something you need to keep an eye on at all times. It is fixable though, and the rewards can be plentiful. Your quality content might soar in the rankings by just getting rid of duplicate content on your site!

Keep reading: ‘ Ask Yoast: webshops and duplicate content’ »

The post Duplicate content: causes and solutions appeared first on Yoast.

You might know that structured data in the form of Schema.org can do wonders for your search results. It also forms the basis for an ever-increasing amount of new and exciting developments on the search engine front. Google has said many times that structured data is beneficial. You can even introduce structured data that Google doesn’t officially endorse yet onto your page. Today, we’re going to look at a new and exciting piece of structured data: the HowTo. This is a how-to about a how-to on HowTo: HowToCeption!

Want rich snippets for your site? Try our Structured data training »

Structured data training Info

What is structured data?

Structured data is a sort of translator for search engines – it adds context to code. By adding Schema.org code, search engines can instantly figure out what every piece of content means, semantically speaking. This gives search engines the power to do cool stuff with your content, like highlighted snippets in search results, the Knowledge Graph or the carousel. There’s structured data for books, articles, courses, events, jobs, local businesses, music, recipes, products, reviews et cetera. Structured data is getting more important by the day and we’ll see more types emerge in the coming years.

If you want to learn more about structured data and find out ow to implement it yourself so you can win those coveted rich results, you can enroll in our Structured data training!

What is HowTo structured data?

According to Schema.org, a HowTo is “an instruction that explains how to achieve a result by performing a sequence of steps.” You can use HowTo structured data to mark up articles that come in a how-to form, but that are not recipes. If there is an element of consumption, it should be a recipe.

HowTo Schema.org was introduced in April 2017, but there is no sign of it yet in search engines. But since Google is increasingly looking at structured data to do cool stuff with, it’s not hard to predict that HowTo will follow soon. Think off it this way, since your Google Home can now read your structured data powered recipes out loud, why shouldn’t it be able to read that how-to on how to fix a leaky faucet or change the busted lights in your kitchen cabinet? There is already talk of Google getting partners interested in a sponsored how-to video deal, as reported by CNBC, which might just be powered by HowTo Schema.org.

Experimental and no support — yet!

This tutorial is purely to let you see what this HowTo structured data is all about. There’s no need to rush out right away and start adding this to your site. But do keep an eye on this, though, because we think it will arrive sooner rather than later. We also don’t know yet how Google will support it and which properties and it will required to get it to function. So, don’t take this post as gospel. With that said, let’s get going!

HTML code

To start, we need a piece of HTML to test our HowTo on. This is going to be a very simple example of a basic page with some content. We are going to base our content on a Knowledge base article about connecting Yoast SEO to Google Search Console. We’re going to mark up every piece of the HTML with HowTo Schema.org in the form of JSON-LD, as this is the preferable format. The content is nothing special, just a couple of steps following instructions. Below you can find the HTML for this page, slightly truncated.

<div>
	<strong>How To Add Your Website To Google Search Console</strong>
	<div>Cost: Free</div>
	<div>Time needed: About 10 minutes</div>
	<div>Necessary items:</div>
	<div>Yoast SEO</div>
	<div>Google Search Console</div>
	<div>
	<div>Preparation</div>
	<div>
		<div>
		<img src="yoast_seo_search_console.jpg" />
		Install Yoast SEO and activate your Google Search Console.
		</div>
	</div>
	<div>
		<div>
		Tip: Did you know you can check and fix crawl errors directly from Yoast SEO?
		</div>
	</div>
	</div>
	<div>
	<div>Adding your site to Search Console</div>
	<div>
		<div>
		Go to Google Search Console (former Google Webmaster Tools), sign into your Google account and click the red button to add your website.
		</div>
	</div>
	<div>
		<div>
		<img src="yoast_seo_search_console_2.jpg" />
		Copy the code for the HTML tag under the Alternate Methods tab.
		</div>
		<div>
		Tip: Please make sure you enter your complete url.
		</div>
	</div>
	<div>
		<div>
		Copy the code for the HTML tag under the Alternate Methods tab.
		</div>
		<div>
		Log in to your WordPress website and cick on ‘SEO’ in your menu. After that, click on General.
		</div>
		<div>
		Click on the ‘Webmaster Tools’ tab and add the code under ‘Google Search Console’. Click ‘Save Changes’.
		</div>
		<div>
		Switch back to Google Search Console (formerly Google Webmaster Tools) and click ‘Verify’.
		</div>
	</div>
	</div>
	<div>
	<div>Finishing up</div>
	<div>
		<div>
		Congratulations! You’ve connected your website to Google Search Console (former Google Webmaster Tools)!
		</div>
	</div>
	<div>
		<div>
		Now that you’ve verified and connected your website, you can submit your sitemap!
		</div>
	</div>
	</div>
</div>

Adding Schema.org

In the example, we’re breaking up the how-to in three parts: preparation, step-by-step directions and finishing the project. All three steps can be wrapped in a HowToSection, with individual HowToSteps and HowToDirections. You can even given an extra HowToTip if you want to add a relevant tip that can improve the job, but is not necessary for the end result. These are the building blocks that define the structure of the data.

So, let’s take a closer look at some of the parts used to build this how-to. Remember, there’s more to find on Schema.org/HowTo. These are some of the parts you will use often:

  • HowTo: To define that this data is a set of instructions to achieve something
    • Name: What’s the project called?
    • EstimatedCost: How much do the tools cost for instance?
      • MonetaryAmount: What currency is and for which amount?
    • TotalTime: How long does the job take? You can also specify a prepTime for preparation.
    • HowToTool: Which tools do you need? Maybe a hammer?
      • Supply: Do you need supply as well, like nails?
    • HowToItem: Which items do you need?
      • Name: Name of the item, list ‘em all
  • HowToSection: Is it preparation, starting or finishing up?
    • HowToStep: Every step needs its own type
      • HowToDirection: Descriptions for the step
      • BeforeMedia: An image of what the starting point looks like.
    • DuringMedia: You can add images or videos per step
    • AfterMedia: And even an image showing the endresult
    • HowToTip: if you want to give extra tips and tricks

You’ll see that the code is fairly straightforward: everything has a clear description. You can expand this code with a lot of properties from CreativeWork and some from Thing as well.

And now, the JSON-LD code

As you might know, JSON-LD is Google’s perfered data format for adding structured data. It’s easy to add since it isn’t embedded in the HTML code. In addition, it is very readable for humans. When running the code through Google’s Structured Data Testing Tool you might see that some variations give errors. For instance, if you use howToItem to determine which tools you need, you get an error, but if you use HowToTool it works perfectly fine. Same goes for supply and howToSupply. Keep in mind that the difference between supply and tool is that the former is consumed while doing the job. A hammer is a tool, while nails are its supply. You need both to finish your work, right? In our example, I could add a ‘computer’, an ‘internet connection’ or a ‘website’ as supply if I wanted to. You can also add a yield to determine what the outcome of the workshop is.

Get the most out of Yoast SEO, learn every feature and best practice in our Yoast SEO for WordPress plugin training! »

Yoast SEO for WordPress plugin training Info

<script type="application/ld+json">
{
	"@context":"http://schema.org",
	"@type":"HowTo",
	"name":"How To Add Your Website To Google Search Console",
	"estimatedCost":
	{
	"@type":"MonetaryAmount",
	"currency":"USD",
	"value":"0"
	},
	"totalTime":"00:10:00",
	"tool":
	[
	{
		"@type":"HowToTool",
		"name":"Yoast SEO WordPress plugin"
	},
	{
		"@type":"HowToTool",
		"name":"Google Search Console account"
	}
	],
	"steps":
	[
	{
		"@type":"HowToSection",
		"name":"Preparation",
		"itemListElement":
		[
		{
			"@type":"HowToStep",
			"itemListElement":
			[
			{
				"@type":"HowToDirection",
				"description":"Install Yoast SEO and activate your Google Search Console.",
				"duringMedia":
				{
				"@type":"ImageObject",
				"contentUrl":"yoast_seo_search_console.jpg"
				}
			},
			{
				"@type":"HowToTip",
				"description":"Did you know you can check and fix crawl errors directly from Yoast SEO?"
			}
			]
		},
		{
		}
		]
	},
	{
		"@type":"HowToSection",
		"name":"Adding your site to Search Console",
		"itemListElement":
		[
		{
			"@type":"HowToStep",
			"itemListElement":
			{
			"@type":"HowToDirection",
			"description":"Go to Google Search Console (former Google Webmaster Tools), sign into your Google account and click the red button to add your website."
			}
		},
		{
			"@type":"HowToStep",
			"itemListElement":
			[
			{
				"@type":"HowToDirection",
				"description":"Copy the code for the HTML tag under the Alternate Methods tab.",
				"duringMedia":
				{
				"@type":"ImageObject",
				"contentUrl":"yoast_seo_search_console_2.jpg"
				}
			},
			{
				"@type":"HowToTip",
				"description":"Please make sure you enter your complete url."
			}
			]
		},
		{
			"@type":"HowToStep",
			"itemListElement":
			{
			"@type":"HowToDirection",
			"description":"Copy the code for the HTML tag under the Alternate Methods tab."
			}
		},
		{
			"@type":"HowToStep",
			"itemListElement":
			{
			"@type":"HowToDirection",
			"description":"Log in to your WordPress website and click on ‘SEO’ in your menu. After that, click on General."
			}
		},
		{
			"@type":"HowToStep",
			"itemListElement":
			[
			{
				"@type":"HowToDirection",
				"description":"Click on the ‘Webmaster Tools’ tab and add the code under ‘Google Search Console’. Click ‘Save Changes’."
			},
				{
			"@type":"HowToStep",
			"itemListElement":
			{
			"@type":"HowToDirection",
			"description":"Switch back to Google Search Console (formerly Google Webmaster Tools) and click ‘Verify’."
			}
		}
			]
		}
		]
	},
	{
		"@type":"HowToSection",
		"name":"Finishing up",
		"itemListElement":
		[
		{
			"@type":"HowToStep",
			"itemListElement":
			{
			"@type":"HowToDirection",
			"description":"Congratulations! You’ve connected your website to Google Search Console (former Google Webmaster Tools)!"
			}
		},
		{
			"@type":"HowToStep",
			"itemListElement":
			{
			"@type":"HowToDirection",
			"description":"Now that you’ve verified and connected your website, you can submit your sitemap!"
			}
		}
		]
	}
	]
}
</script>

Adding structured data to your site with Google Tag Manager

Adding structured data requires you to edit the code of your pages. For most people, that requires help of their developers. There is an easier way, though. You can add structured data via the tags, triggers and variables available in Google Tag manager. What’s more, this way of adding your data gives you an extra amount of flexibility as you can save your variables and reuse them or even dynamically fill them. There are loads of options to explore. Annelieke wrote a post on how to add structured data to your site with Google Tag Manager.

A fun experiment

This was cool, right? Well, you might try to apply this on a live site, but keep in mind that search engines probably won’t do anything with it. Also, keep in mind that badly written or faulty structured data can do your site more harm than good. But — and there’s a big but —, since Google is heavily focusing on structured data and voice search via its Assistant, it’s fairly safe to say that howTo Schema.org will be next in line. As this is a new Schema.org, we’ll just have to wait for the official word from Google to arrive so we know how to apply this properly.

Read more: ‘Structured data: the ultimate guide’ »

The post How to add HowTo structured data to your how-to article appeared first on Yoast.

Today’s Ask Yoast will discuss a problem that may be familiar to you if your site is in a non-ASCII language, like Arabic, Persian, Hebrew and many other languages. You work hard to write good, SEO-friendly URLs, so people will click to your website. However, when your site is linked to or shared, for instance on social media, the slug doesn’t show the right characters. Instead, it changes into a long string of percent signs, capitals and numbers.

To give you an example: check out this link to an Arabic Wikipedia article on SEO. In the address bar, it looks good:

arabic URL in address bar

However, when I try to copy it into this post, it turns into this:

arabic URL copy-pasted

Of course, a slug like that looks weird and a bit unsettling: it doesn’t tempt people to click, and doesn’t reveal much about the content of a page either. So, if you come across this problem with your non-ASCII slugs, what are your options for dealing with this?

Optimize your site for search & social media and keep it optimized with Yoast SEO Premium »

Yoast SEO: the #1 WordPress SEO plugin Info

Ahmed Saad emailed us on this subject:

My site’s content is in Arabic and that means that the slug looks very bad when it’s shared on social media. Should I change the URL language to English so it looks better or does that hurt my SEO?

Watch the video or read the transcript further down the page for my answer!

Dealing with bad slugs for Arabic URLs

‘I honestly don’t have a good answer to that because this slug is not good for your SEO either. This slug doesn’t really entice people to click. I guess that the best solution would be to get the shortest slug as possible in Arabic, because you can have i18n URLs. But support for that is not always as good across CMSes.

If that doesn’t work then you can certainly fall back to English, or to an English ‘way’ of writing your Arabic strings, which is something that a lot of Indian languages do. Good luck!’

Ask Yoast

In the series Ask Yoast, we answer SEO questions from our readers. Have an SEO-related question? Maybe we can help you out! Send an email to ask@yoast.com.

Note: please check our blog and knowledge base first, the answer to your question may already be out there! For urgent questions, for example about our plugin not working properly, we’d like to refer you to our support page.

Read more: ‘How to create SEO-friendly copy in a foreign language’ »

The post Ask Yoast: Bad slug for Arabic URLs appeared first on Yoast.

Your site needs to be up and running if you want to be found in search engines. If you aren’t blocking anything — deliberately or accidentally — search engine spiders can crawl and index it. You probably know that Yoast SEO has lots of options to determine what does and doesn’t need to be indexed, but did you know it also has a check that monitors your site’s indexability? This is the indexability check, provided by our good friends at Ryte.

Optimize your site for search & social media and keep it optimized with Yoast SEO Premium »

Yoast SEO: the #1 WordPress SEO plugin Info

What does it do?

The indexability check checks regularly if your site is indexable. You can find the Ryte indexability check on your site’s dashboard inside the Yoast SEO Posts Overview box. It is straightforward to use as it is just a colored bullet showing the indexability status of your site:

  • Green: All is well, your site is indexable.
  • Grey: Yoast SEO hasn’t been able to determine the status of your site.
  • Red: Your homepage cannot be indexed, and you should look into this immediately.

Dashboard overview Yoast SEORemember, something is up if you should ever get a red bullet. If you do get one, and you are sure your site should be indexable, please check if your site is available by running a Mobile-friendly test by Google. Your site should appear if it is indexable. If it does, it might be that Ryte had the hiccups.

Should Google be unable to run the test, you could hit the ‘Analyze entire site’ button in your WordPress backend and follow the instructions given by Ryte. Sign up with them and give your site the once-over. The phenomenal Ryte suite gives you loads of advice on how to cope with indexability errors and more.

A grey bullet means that your server is unable to connect to the Ryte servers to get the indexability status of your site. There are several reasons why this could be the case. Please see the Indexability check fails post on our knowledge base for more information on how to evaluate and fix this.

What do I have to do to get it?

We add this check automatically when you install Yoast SEO. Find it in your WordPress dashboard. If it doesn’t show a green bullet, you can manually run a check by clicking ‘Fetch the current status’ button inside the Yoast SEO Posts Overview box.

If you don’t need the Ryte indexability check, you can always turn it off. Go to General > Features in Yoast SEO and switch the Ryte integration button to off.

Yoast & Ryte

Ryte & Yoast SEO

Ryte offers a free indexability check for Yoast SEO users. This way, you can quickly see that your site is still reachable for both search engines and visitors. If you need help fixing technical SEO issues or if you are in need of a great suite of SEO tools to help you fix or improve your rankings, you can always sign up for the free Ryte introductory plan. Just hit the purple ‘Analyze entire site’ button and follow the instructions!

Read more: ‘SEO basics: What is crawlability’ »

The post Yoast SEO & Ryte: Checking your site’s indexability appeared first on Yoast.

On March 6, we released a major update of our Yoast SEO plugin. This update was aimed at making SEO easier and more understandable for our users. We removed quite a few settings and options. In other cases, we changed the names of settings making them easier to understand for non-technical users. All in all, the reactions on this update were rather positive. We received some questions as well, mostly about why we removed certain settings and options. In this post, I’ll explain why we chose to remove those settings. 

Get the most out of Yoast SEO, learn every feature and best practice in our Yoast SEO for WordPress training! »

Yoast SEO for WordPress training Info

If there’s a button, people want to click it

The main reason why we deleted settings is because in 99% of the cases it should not be altered. But if you give people a toggle or a button, generally they’ll think they have to do something with that toggle or button. Totally understandable. If I have a new watch and it has many fancy buttons, I’d also want to know what they’ll do. By offering all those settings, we gave the impression that our users needed to do something with these settings.

The things we removed were the things people should not worry about: the things that didn’t make much of a difference in their chance of ranking in the search engines. These buttons and toggles were rather useless anyway.

More agreement on proper SEO settings

Working on our new online Yoast SEO plugin training helped us to make the plugin more understandable for a large audience. We had to really make an effort when explaining the settings in videos and text. And we noticed we had a hard time explaining some of the things. It made us question and reassess our decisions. That process lead to a lot of the changes made in the plugin release of March 6.

On top of that, there was another reason why we decided to remove quite a few settings from our plugin. For a long time, the SEO community had strong and opposing opinions about the need of, for example, XML sitemaps. Because of these different opinions, we always offered different options, allowing people to make their own SEO choices. As the profession of SEO matured, SEOs reached more consensus on what things were important to rank high in the search engines. As those influences are rather clear nowadays, we were able to make those changes in the plugin. Important changes, because now, the ease of use of our plugin is improved.

SEO for everyone

The mission of Yoast is SEO for everyone. We believe the web will benefit from all people having an equal chance in the search results. Not only those big international companies with large marketing budgets, but also that small online shop with handmade toys. We believe every idea should get a fair chance in the search results.

When developing our plugin, we always keep our mission in mind. And that’s the reason why we recently decided to make some big changes in our plugin. We really hope that more people will be able to benefit from our plugin. If you really want to know all the ins and outs of Yoast SEO, I would strongly advice you to buy and follow our online plugin course. It will help you to get the most out of our plugin. Because, although we deleted quite a few settings, we still have a lot of toggles, settings and choices left :-) Good luck!

Get the Yoast SEO training Now$39 for course, certificate and badge

The post Why we changed so many things in the 7.0 update appeared first on Yoast.

One page websites have been popular for some time now. Basically, it’s your entire website on your homepage. It’s fancy, it’s streamlined. By dividing your homepage into multiple sections, and adding a menu that allows visitors to jump to the section they want to visit, you create an entire website experience on that one single page. Having just one single page also means that you probably need to rank that page for multiple keywords. And that’s where one page website SEO differs from regular website SEO: there are just fewer things you can optimize.

Optimize your site for search & social media and keep it optimized with Yoast SEO Premium »

Yoast SEO: the #1 WordPress SEO plugin Info

Why use a one page website?

Truth be told: I don’t like one page websites. There are a lot of people that like all their content crammed into one page, but I just can’t see the benefit of it. The page loads slower, there is less focus, I detest loading the JavaScript/CSS scripts that make unnecessary visual movements or automatic scrolling possible. Don’t get me wrong: there’s nothing against having long pages. I love ’em and write ’em. But I’d like to keep these pages focused on one subject.

One page website SEO tips and tricks

Is there anything you can do to optimize your one page website for SEO? Of course, there is. There always is. I’m just not sure you’ll enjoy that single page website for your company in the long run. One page website SEO is tough. I think the only reason you’d want a website like that, is when you need to set up a quick promotional site. Say for a particular product or a temporary collaboration with another brand. In that case, you’ll be driving traffic from flyers, TV ads and the works, and are less dependent on search engines.

If you insist on using a single page website, you need to pay attention to the way you set things up.

Optimize per section

Before starting to write your content, you need to do some keyword mapping. As you have only one page to tell your story, group related content. Create a <div> or <section> for each keyword and assign a proper ID to it. If a section is about trimming hairy dogs, use trim-hairy-dogs as the ID, as this will be like the slug of that particular section. Your internal links on that page will link to example.com/#trim-hairy-dogs. Choose that slug wisely.

That section needs content and a heading and as we think of all these sections as “pages”, you should add an <h1> tag to these sections. That indeed means multiple H1s per page, but hey, you wanted an unfocused website.

If you use images, optimize image file names and ALT tags per section as well.

Optimize page speed

This one is vital for your one page website SEO: optimize page speed. It’s even more critical if you have a page like that since you are serving all kinds of different sections with possibly all types of different layouts and design elements, so your page doesn’t look like a Word document, right? Most of these elements simply take time to load, and you want to optimize that. Here are some articles that will help you optimize speed.

One page website SEO: Add fresh content

Fresh content for the win

You are probably still not convinced that you’d better create multiple pages on your website. But you will understand single page website SEO is pretty hard and limited. You have one page in search result pages, one canonical link, one page that needs to rank for everything you want to rank for. Fresh content, dynamic content, is always a good idea and it is possible on a one page website. Rewrite your sections now and then to align them with current events, for instance. If your website is set up once, and never changes, you have this one static page that needs to do all the work. Changing its content from time to time will certainly help.

One more thing: Analytics

It is possible to track internal links on that page: track per section. But that’s fairly hard for the average Google Analytics user. And Google would rather track per page as well, judging from this article. This is yet another reason why I don’t like one page website SEO. It’s harder to implement SEO recommendations and harder to analyze your efforts.

Come to think of it; it’s probably your PR agency or sales department that likes that one page website so much. So please, please reconsider setting up a page like this. It’ll make your SEO so much easier.

Read more: ‘Why every website needs Yoast SEO’ »

The post Optimizing a single page: One page website SEO appeared first on Yoast.