The SEO Project

Every SEO project has two parts: the SEO platform and SEO processes. In this chapter, we will cover in detail the SEO project including the platform, the importance of your site speed, URLs, targeting, and targeted pages.

Establishing the SEO platform is mostly, but not entirely, a technical task. It focuses on optimizing the technical infrastructure and application so that it allows for scalable SEO instead of hindering it. Although you can always improve the platform, at some point it will be good enough to enable sustainable traffic growth via search. Before we get into the details, it’s important to remember:

• everything accessible pre-login is within SEO scope
• everything exclusively accessible behind a login is not within SEO scope

And, for a healthy SEO platform you will need:

• targeted pages
• distribution (sitemap.xml)
• a startpage

Everything else is “deadweight” and should either not exist or not be indexed.

User Experience

Remember my favorite rules from chapter three? Always start with the user! If your users come to your site via search but don’t use your site and bounce back immediately, you:

• probably did not create much value for your users,
• did not create any value for your business, and
• will not be able to sustain this traffic for very long.

User Experience is not SEO. It’s a massive discipline with lots of different goals and techniques, and it’s still evolving. From a pure SEO perspective, you should always aim that your user experience is better, or at least on par, with that of the competition.

As you probably don’t have the usage metrics of their websites, it’s best to look at their site. Ask yourself what they are doing better, assess if it would make sense on your site, then copy and iterate on it. That is the way the internet works.

A Red Line

A site with a bounce rate (where users are coming from search and are only viewing one page in one session) of more than 70% will not survive. That is the red line. If you have a bounce rate of 70% or above, do not waste time on SEO. Focus on fixing your site and your value proposition first.

That is the red line because it means that fewer than 30% of your users view more than one page. It means seven out of every ten visitors do absolutely nothing, leaving immediately and generally go straight back to Google and on to your competitors.

But even then people say “What if they bounce forward or do nothing? Aren’t only the bounces back to Google harmful?” My answer is, “Yes, you are right. If the user stays on your site or bounces forward to another site, this is not a negative SEO vote - but it still means your site sucks!”

If you have a bounce rate of more than 70% in any vertical, then it’s not the user, it’s not the vertical, it’s you. If you insist that you only have such a high bounce rate because the “goal of the user was fulfilled,” then I say you must work on your value proposition. Nevertheless, I have never seen a website that couldn’t lower its bounce rate below the red line with some simple user experience improvements.

In general, the UX of your site should get better and not worse. Better means:

• a gradual decrease in bounce rate
• a gradual increase in time on site
• a gradual increase in average pageviews

Note: These are metrics that you can easily measure and act upon. That’s why they are important. These are not the metrics that Google uses. They have their own way of collecting UX data, data that we do not have.

Google does not use Google Analytics to measure the UX values on your site. So no, it does not help to “tweak” GA to show better usage values, that is just lying to yourself, and lying to yourself doesn’t work in the long term.

To achieve better UX values over time, you need to deliver direct feedback to the people that work with your site (your marketing, development and content teams). Give those people access to your metrics and make it part of their job description to watch, respond and improve these valuable numbers.

Unfortunately, I often see that it’s the other way round. Usage metrics get gradually worse with every release or new feature. You must always strive and fight to get better UX, and the people that work with the site need to know and care about THEIR site’s usage metrics.

So, what the most important aspect of the user experience? Quite often it’s speed.

Speed

Speed is something we must deliver. Speed is part of UX and brand experience and a crucial topic in its own right. Or from a Google point of view: Google does not like to send useres to slow pages, as the users would use Google less. And Google does not like that. Google can measure speed both directly and via the user experience feedback loop.

Fast websites perform better in search. They have better UX and deliver a better brand experience. Slow websites are synonymous with having a “clunky, old, outdated” brand and will always underperform. So, what exactly is defined as “fast”? Here is what you should be aiming for on desktop and mobile sites (both HTTP and HTTPS):

• first byte: < 200ms
• start render: < 700ms
• render above the fold: < 1000ms

The first byte is the time it takes for your server to return something to the user’s browser for the first time. The start render is the moment when the browser first starts to render something visible to the user, so they know something is happening. The render above the fold is when the visible content - without scrolling in the browser - has been correctly rendered.

You will have a hard time to get the first byte of < 200ms on mobile, but you should still achieve the one second above the fold as there is much less fold. The most important metrics are the “start render” and “render above the fold” times. However, the start render can be misleading because the first visible content is not necessarily useful to the user (for example, it may just be a background color).

There is an acceptable zone if these web performance values are doubled. It’s not fast, it’s not slow, it’s OK-ish, but you should and could do better.

So, what are “OK-ish” speed metrics?

• first byte: < 400ms
• start render: < 1.4 sec
• render above the fold: < 2000ms

Anything above these values is “kaput” - a great German word meaning completely and utterly broken. Your site will never achieve sustainable, growing traffic.

So, your goal from an SEO perspective and a UX perspective is to have a fast site, not an OK-ish one. If you have a slow website (anything above the acceptable values), then stop everything and fix your site, because your site is broken. In this case there just is no more important business decision you can make right now than to make your site fast.

So how can you test the speed of your site?

www.webpagetest.org is a Google supported project. Just enter your page URLs (obviously not only the startpage but all kinds of pages on your site), choose a location and a browser and start testing. Note that “render above the fold” is basically the same as “Page Speed Index” on webpagetest.org. Other very important webperformance tools are

• Google Page Speed Insights
• Google Lighthouse

as there is not one single tool, not one single metric that can capture the whole role of webperformance for user experience.

Basically Google Page Speed Insights tells you how many webperformance best practices are in place on the webpages you test, and if there is enough data: how fast users experience your webpages. Google Lighthouse - included in the Developer Tools of every Google Chrome browser - calculate metrics how fast mobile users can view and interact with your website.

And how can you make your site faster?

To get you started, I recommend this approach: Get rid of onpage deadweight! Delete anything you do not need on your web pages. Unnecessary icons? Delete. Small decorative images? Delete. External fonts? I hate fonts, burn them. If you have third party rubbish that nobody uses, get rid of it. Evaluate everything on your page with a critical stance, and if necessary, delete whole page sections. Speed is more important than elaborate design.

Note: you can have a fast site with fonts and icons, but it is hard. If you are suffering from slow speeds, my recommendation is to delete that rubbish. Your users do not need it, and it’s holding you back. Once you have a fast site, you can think about adding fonts and other stuff that you need because of “reasons.”

You can test a variety of your pages and get recommendations on the steps to take using Google Page Speed Insights. Proceed with Google Page Speed Insights and read all the recommendations of this tool and do all of them, even the minor suggestions - you will find they add up to substantial improvements.

After each improvement, check your speed with webpagetest.org. Do not stop until each and every value is in the “green” on Page Speed Insights. Page Speed Insights is the most direct way that Google communicates to you if you have a speed issue.

After you have fixed all this, go to Google Lighthouse, start an audit and follow the recommendations in the “Opportunities” and “Diagnostics” sections. Don’t be afraid of the blue, underlined “Learn more” links. Click them, learn more, fix things.

Always make sure that your developers (server, backend, and frontend) care about speed. A new feature, a new design, a new database server must never make the site slower. If you have to choose between a new feature and speed, choose speed!

The speed topic will stay with you as long as you run a website; it will never end. Having a fast website is a significant competitive advantage, having a slow website is online business suicide. Next up: URLs - be sure to get them right.

URL Rules

SEOs love to talk about URLs. Why? URLs are at the intersection of development, marketing, and content. The URL is analogous to the API endpoint of your technical application. It’s a defining part of your website.

All URLs on a webproperty must be according to the rules listed below. Follow these rules, and you will keep your site manageable, logical, and prevent naming collisions. You will also be able to analyze different site sections using Google Analytics and Google Search Console.

URL Rules

1. URLs must be unique.
2. URLs must be permanent.
3. URLs must be manageable.
4. URLs must be scalable.
5. URLs must be short.
6. URLs should include a short variation of the targeted phrase.

The URL rules listed above are by culminated priority. That means rule number one is more important than rules two to six put together; rule number two is more important than rules three to six put together and so on. Rules number five and six are always a tradeoff, with six being the least important rule. Search engine optimized URLs must fulfill all URL rules to be truly optimized. Let’s discuss each rule in more detail.

URL Rule 1: URLs must be unique (one URL = one resource, one resource = one URL)

A URL points to one and one thing only (it is a one to one relationship). A URL does not point to two things (it is not a one to many relationship), and one resource (for example, an HTML page) has only one URL. Remember, this rule is more important than all other URL rules put together. If you do not have unique URLs, you cannot systematically optimize your website.

URL Rule 2: URLs must be permanent (they do not change, they have no dependencies on anything)

Once established, your URLs must not change. They must point to one thing and one thing only. However, it is sometimes unavoidable that URLs change. Be aware, if you change a URL, you are, from an SEO perspective, deleting the old page and creating an entirely new page with the same content. You are essentially starting from scratch again. So make sure that URL changes are extremely rare.

The good news, as you probably know, is that you can migrate from one URL to the another. For this, you have to point a HTTP 301 permanent redirect from the old URL to the new URL (just one direct redirect, not redirect chains). Then you have to change all links (within your direct or indirect influence) to point to the new URL.

A successful migration will have no permanent negative SEO impact. Nevertheless, most migrations for complex medium or large web properties are not successful. Therefore, the only good reason to proactively change URLs is when you cannot guarantee URL rule number one (uniqueness). In such cases, it’s best practice to move to a completely search engine optimized URL logic altogether and then stick to it. This rule is more important than rules three, four, five and six combined.

Pro-tip: Never have categories in the URL.

It’s perfectly fine to have categories or any other taxonomy or hierarchy as part of one’s information design, but they do not belong in the URL. Why? Categories always change. There is no such thing as a perfect taxonomy.

You can promise, swear and even believe that your categories will never change, and then six months later the categories change. Any kind of hierarchy in the URLs are a major dependency and will lead to a lot of headaches, work and SEO misery down the road.

URL Rule 3: URLs must be manageable

Keep it simple. One URL logic per site section. No exceptions, ever, and I mean it. You should know looking at a URL exactly what it is about, why it exists and why the URL looks the way it does. This rule is more important than URL rule four, five and six combined.

Manageable equals measurable. A bonus of having manageable URL logic is that you can easily make statements about parts of your site (using Google Search Console, Google Analytics and internal logs), rather than your whole site.

URL Rule 4: URLs must be scalable

There must be no limit on how many URLs you can create with one set of URL logic. It must not matter if you have ten or ten thousand of these pages, the URL logic must still work. This rule is more important than URL rule five and six combined.

To be manageable, measurable, and scalable, all pages URLs should include a short namespace that hints at their page type. Aim to give every page type its own namespace. For example:

• https://www.example.com/a/understanding-seo (where “a” is an article page), or
• https://www.example.com/c/seo (where “c” is a category page), or
• https://www.example.com/t/stuff (where “t” is another page type)

Remember, do not write the whole name of the namespace in there (we want URLs to be permanent! As soon as you name things you have a dependency that might change over time).

URL Rule 5: URLs must be short

Do not confuse “short” with the “shortest possible.” The URL must only include the parts that are necessary to render the page. Nothing more, nothing less. “Short” is a fluffy metric, I know. If you want a hard metric: If your URL is longer than 70 characters, then your URL is probably too long.

Keep in mind: If you need an ID to render a page (because of URL rule three and four), use the ID in the URL. If you can - in any way - substitute the ID with a short variation of the targeted phrase (which we will be discussing shortly), then ditch the ID.

If you cannot get rid of the ID, then the variation of the targeted phrase is - most of the time - overhead. Most of the time, because if you manage to keep the ID and targeted phrase short, you might be good to go. Rule 5 is always considered a trade off with URL rule number six.

URL Rule 6: URLs should include a short variation of the targeted phrase

We will talk more about targeted phrases shortly, but know that this is the least important of all the URL rules. It’s a tradeoff with rule number five (keeping it short), and that’s why you should never include your whole targeted phrase into the URL. It should be a short sensemaking variation or only a part of the targeted phase.

URL Best Practices (Make Your Life Easy)

Now that we’ve outlined the rules, here’s a few additional best practices for URLs:

• URLs should always be lowercase
• only use the letters a-z, the numbers 0-9 and “-” in URLs
• always use a single dash “-” as a word separator
• never use “_” underscores, they are not considered word separators
• there should be no double spaces in URLs (“ ”, “-----”, “++” are always substituted with one “-”)
• there should be no spaces (“-”) at the end or beginning of a URL

Designing the optimal URL logic should be a one time effort. At the end of the day, even after you have dissected all the URL rules and best practices listed above, try to remember you shouldn’t overdo the f*cking URLs.

Implement URL rule one to four once so that they work for all eternity, and run automated tests to make sure that they do. Try hard to get rule five and six right. And then live with the outcome. See the “Best Practices for Targeted Pages” section for some URL best practice examples.

Targeted Page Generation Logic (a.k.a. Targeting)

Now that we’ve discussed speed and URLs, it’s time to talk about pages that target user queries. If we want to get found for a query a user searches, we need a page that targets this query. This user’s query becomes our “Targeted Search Intent Phrase”, or “Targeted Phrase”: the phrase we want a specific page to be found for. Every targeted page targets exactly one dominant targeted phrase.

I use the term “Targeted Phrase” instead of just “keyword” because “keyword” implies that we are putting keywords into a text, which we are not. Also, “keyword” is confusing as there is also the meta-keyword tag which is not good for anything. It is important that you realize that on these pages you are really targeting search intent, whereby we need to work with the textual representation of this intent.

For example, if you want to get found for [toyota insurance] (the dominant targeted phrase) you do not need to create extra pages for slight variations, such as:

• Toyota insurances
• Toyota car insurances
• Toyota car insurance

“Toyota insurance” is the dominant targeted phrase that you need to worry about. The others are reasonable variations, and Google is fairly good at handling singular and plural, as well as determining that Toyota is in most markets mainly seen as a brand of cars. We will target the slight variations “together” with the dominant targeted phrase.

Targeting each and every slight variation (especially singular and plural) of a term with multiple pages can lead to internal competition and a lower performance of these pages. We are not targeting the “keywords” but the search intent behind them. One search intent, one page targeted at one dominant targeted phrase plus slight variations.

Next up, never target misspellings. Google corrects them anyway, and deliberate misspellings are bad UX and will be perceived as spammy. Again, you are not targeting text, you are targeting search intent.

Continuing our example, “Toyota motorcycle insurance” might be another dominant targeted phrase that deserves its own page. It is your call whether something is a targeted phrase in its own right or whether it’s just a slight variation. If the search intent of the user is the same, then it’s a slight variation. If the search intent of the user is a different one, then it’s a targeted phrase in its own right.

The process of targeting involves creating an inventory (pages on your webproperty) for existing or presumed search demand (user queries). The most common way to decide what queries to target are:

• Editorial Search Demand Research
• Database Driven Targeting
• Database Crossing Targeting
• Query-Driven Targeting

Before understanding how effective targeting works, however, you first need to understand The Quality Criteria.

The Quality Criteria (QC)

The Quality Criteria is an editorial or automatic process that must be applied to every page. The Quality Criteria is what differentiates targeted pages from pages that are a deadweight to your webproperty. And deadweight should either not exist or not get indexed.

For example, do you have a page on your site that targets [viagra]? If you are not a spammer or not in the pharmaceutical business then probably not. Why don’t you have such a page? Because it doesn’t make sense for your business. You have no need for such a page. That is already some kind of editorial QC.

The QC can be applied either during targeting (deciding if a page should exist or not) or during distribution (deciding if we communicate a page to Google). It can be human (an editorial decision, which is a strong QC) or automatic (for example, based on the content of a page we decide if we create and distribute it or not).

Regardless of how it is implemented, the important part is that you need QC! You need a quality standard for your website, and you need to apply this criteria to all of your web pages.

The primary job of the QC is to ensure that the page fulfills the quality standard of your company. You would not believe how many websites there are with a good quality product but a horrible, low quality, even spammy website. These websites hurt your company. For most new customers, your website is your company, and a positive first impression is crucial.

Additionally, the QC must prevent negative SEO impact from:

• off-topic pages
• low quality and spammy pages
• internal duplicate content
• internal duplicate targeting
• external duplicate content

We will revisit the QC constantly whenever we talk about targeting, content, and distribution.

Editorial Search Demand Research Targeting Page Creation

Editorial Search Demand Research Targeting Page Creation is the simple process when an editor (a content person, writer, editor, journalist or copywriter) considers what pages to create “for the user.”

The editor tries to guess a targeted phrase and then checks with:

• Google Autocomplete / Google Suggest (the dropdown of recommendations whenever you google something)
• Google Trends
• maybe even in some edge cases the Google Keyword Planner

If the hypothetical targeted phrase makes sense (and if the user actually does search this way), they then go on to create a page with the appropriate content. The QC, in this case, is very strong - it’s a human concerned with the best interests of the company. The editor will go on to create unique content (by personally writing it), which is another strong QC.

That is the targeting logic for most blogs, magazines, and editorial websites. It’s a good, simple process but sadly it scales very poorly.

Database Driven Targeting Page Generation

If you have a database (DB) of content, you may be tempted to generate targeted pages for the data that passes your QC.

For example, if you have a database of business names and addresses, you could decide to create a simple company listing site (like Yellow Pages). You determine that for every database entry, you will create a page targeting that business name.

Of course, you apply some minimal QC - if there is no address or telephone number, you don’t create a page. Additionally, if you already have a page for that business name, you don’t create a new page (there are always a lot of duplicates in big datasets).

Therefore, your QC logic would be:

• business name + telephone number = new page
• don’t create duplicates

This simple logic completely ignores the case of external duplicate content. If you have “fat content” (that is paragraphs of text such as business descriptions as opposed to just a list of opening hours), you need another quality criteria to filter out all the external duplicate business descriptions. As an alternative, you could have another QC that guarantees that no external duplicate “fat content” exists in the database.

Database Crossing Targeting

The advanced version of database generating content involves combining multiple databases, filtering it through quality criteria and then creating lots and lots of targeted pages.

For example, if you have a set of categories and apply it to your inventory of other content, such as articles, offers, and addresses, you could create a targeted page for each category if the page fulfills a pre-defined QC. A sample QC could be that every category page must have at least three entries. Otherwise, it will not get created.

Let’s do an example by revisiting our simple business listings site again. We have a DB with business addresses, a separate DB of categories (for instance, broad business types) and a DB of locations (for example, a list of cities). We apply the locations to the addresses so that we group the businesses by location.

Additionally, we apply our categories to the location enhanced businesses; now we can create targeted pages for all categories for all locations, for example, “Copy Shops in Berghausen, Austria.”

Great, at this point we have spammed ourselves with an unbelievable amount of no-content pages (there are no copy shops in Berghausen). That’s because we did not apply any QC yet.

Ah ha! A sample QC would be that we only create pages where there are a lot of businesses, for example, “only create pages with at least 15 addresses” (a content dependent QC). Note: the number is not the important part here, it can be 2, 10, 20, 100, whatever makes sense. Generally, it’s a good idea to start with a high QC and lower it over time.

There are many creative ways to combine databases to create targeted pages, but never do it without applying hard QC to these pages. If you cross databases without explicit, outspoken and specified QC, you will spam yourself, and you will suddenly have millions of deadweight pages.

Query-Driven Targeting

Query-driven targeting is very easy to do poorly, and very hard to do right. With query-driven targeting we can use real user queries to create targeted pages.

We take a user search query - from any source we can get our hands on, for example, the logs of our internal search, and apply it to our database (so, we make a search of our available material).

If the page fulfills a particular requirement (for instance, there are more than x items found, and there is no other page on your site that targets a similar term, and there is no page on your site that shows the same list of items), then we create a targeted page. If this quite complex QC is not fulfilled, then don’t create the page.

Some call these “search pages,” and yes, search pages are query-driven targeted pages but without a QC. If you do it wrong, you will create:

• internal duplicate content
• internal duplicate targeting
• nonsensical pages
• pages with terms that do not align with the goal of your business

To get this right, make sure you use QC on all queries you target.

Pro-tip: Query-driven targeting is very, very, very hard to do right

Start slow. Begin with a very high QC, a fixed set of queries and lots of quality assurance. Learn, lower the QC, add more queries, learn, and continue. If you don’t do it this way, you will spam yourself.

Database Editorial Targeting

Database Editorial Targeting is another form of targeting, and there are a lot of creative and not-so-creative ways to do it. With this technique, you have an editor who creates list pages (via a topic, theme, or collection) through an editorial filter over a database.

A common use case is the creation of topic pages. I.e.: an editor decides, that there should be a page listing all articles for “mothers day”. He/she goes into the backend and creates a targeted list page for it.

Retroactive Targeting

Retroactive targeting is the process of taking an existing page, so a page that is not targeted at a specific targeted phrase, and retrofitting it to make it become a targeted page. Retroactive targeting is one of the reasons why many people hate SEO.

There are a lot of good reasons why pages might exist. An article might be written with a social media audience in mind, or a page might exist because of the top-down navigation (people coming from the startpage and clicking through the navigation). These pages were created to fulfill a particular use case.

If you now take a page that fulfills a particular use case and impose a search use case on top of it, you will get a page that fulfills neither use case. In general, you have made the UX of your site worse.

Yes, you can, of course, create a page that fulfills a top-down navigation use case and a social media use case and the search intent use case. But in nearly all situations it’s not as easy as updating an existing page with a title, headline, and some extra content and then calling it “search engine optimized.” It doesn’t work like this.

If you want to have a targeted page that fulfills top-down navigation and another use case (which is a good idea), then this must be done during the creation of the page, not as a minor, later add-on.

Targeted Pages

So far we’ve discussed how to go about creating targeted pages, and now we are going to talk about what they consist of. A targeted page is a page which:

1. is a HTML page
2. is reachable via only one unique URL
3. is targeted at one - sitewide unique - dominant phrase
4. fulfills a presumed search intent
5. fulfills a business utility
6. hosts unique content or a unique collection of content
7. fulfills a predefined quality criteria (QC)
8. displays content and links visible without user interaction
9. uses exactly one language
10. links to other targeted pages
11. gets linked from at least one other targeted page
12. is listed in the sitemap.xml.

Let’s discuss all these points in detail.

1. A targeted page is a HTML page

Every targeted page must be a HTML document. Even though Google can and does index Flash and PDFs, we only can thoroughly optimize plain old (JS and CSS enhanced) HTML pages. If you deliver the same content via PDF and HTML, the user and Google will nearly always prefer the HTML version. Only HTML pages qualify as optimized (and optimizable) pages.

2. A targeted page is reachable via one unique URL

As URLs are visible in search results, it’s one of the primary things the user sees and learns about your page. In addition to this, URLs are actively communicated in PR and marketing, and by support and sales, both online and offline. And when other websites link to you, they will usually copy and paste the URL.

URLs are part of the content, and a sensemaking URL should give the page context, in a way similar to a headline. URLs are a major technical decision determining what pages can exist. A targeted page is an indexed URL with content in context. One page, one URL. Also see the URL rules.

3. A targeted page is targeted at one sitewide unique phrase

The one sitewide unique phrase is what we want the page to be found for. There should just be one page for that specific targeted phrase and its underlying search intent on your entire webproperty, never more. If there are two pages on one webproperty that have been designed to be found for the same targeted phrase, it is called “internal competition.” Internal competition is confusing for Google and consequently bad for SEO because:

• Google cannot pinpoint the right resource on our website for the user query with absolute certainty, as there are different options.
• Google can pinpoint the right resource on a competing website (with only one page that targets the query) with absolute certainty.

Therefore, Google will choose the competing “certain” pages over our “uncertain” pages. There’s a chance we may show up in search results, but not as well as we would have with just one targeted page per sitewide unique phrase.

There are three common causes for internal competition. They are:

• internal duplicate targeting
• internal duplicate content
• internal duplicate pages

Internal duplicate targeting happens when you create two different pages with different content, but that want to be found for the same targeted phrases. This strategy will underperform. Delete one page or merge them both into one page. Redirect (HTTP 301) the vanished URLs to the new one.

Internal duplicate content happens if you reuse substantial parts of your “fat content” (paragraphs of text) on more than one page. Google cannot lead the user to the one “right” page that content belongs to, and might prefer competing pages where it can easily pinpoint the “right” page.

Internal duplicate content is no issue if it happens “sometimes” as Google is pretty good in leading the users to the right pages. However, if internal duplicate content happens systematically on your webproperty, you have a systematic problem. A gray area exists on whether or not internal duplicate content includes when internally reused content is combined with other content to create a unique combination of content.

Internal duplicate pages, however, happens when you violate URL rule number one (URLs must be unique). These pages will always underperform. Make sure you fulfill the URL rules, then delete the unnecessary URL variations. A failsafe way to prevent unintentional internal duplicate content is the so-called “canonical tag,” which we will discuss later.

Always remember that you should have only one page, with one unique URL, for one unique dominant targeted phrase: 1:1:1. It’s also necessary to note that every page we communicate to Google must have a targeted phrase. Otherwise, it’s deadweight, and either should not exist or not be communicated to Google.

4. A targeted page fulfills a presumed search intent

A page must not only want to be found for a particular term, but it must also meet a search intent. We don’t and never will know the exact search intent of the user. However, we should attempt to solve the “job to be done,” or at least point the user in the right direction. Keep in mind; a page can fulfill more than one search intent if the targeted phrase allows multiple search intent interpretations.

If your page does not solve anything for the user, do not create it. Pages that attempt to answer a “know”-query (where the user wants to know something) with a “do”-intent (complete a transaction), or vice versa will not work. However, it does make sense in a lot of cases to fulfill the possible “know” and “do” intent of a query on one page.

Also, link further if you do not fulfill one of the presumed search intents of the users, even if it’s to your competition. Everything is better than leading the users to a dead end where the only way out is bouncing back to Google.

5. A targeted page fulfills a business utility

This is obvious but needs to be stated anyway. The page must make sense for your business and help you achieve your goals. Therefore only create pages that will contribute to your business goal.

6. A targeted page hosts unique content or a unique collection of content

Unfortunately, it’s not easy to explain what unique content is. However, it’s much easier to explain what “duplicate content” is. We’ve covered internal duplicate content, so now let’s discuss external duplicate content.

External duplicate content is whenever you use copy and paste (or a similar process) and take content from another external, Google indexed (or soon to be indexed) web page and publish it on one of your indexable web pages. This can range from small scale copy and pasting to widespread automatic scraping.

As you are not the first to publish this piece of content, you are left with a high probability that you will not be seen as the authoritative source for this content. In Google Search, this content has either negative or no value for you. We call this “first one wins.”

If you have lots of pages with external duplicate content on your website, not only do the pages with this duplicate content not perform but also all web pages of your site will be worse off. There is no fixed percentage of when minor external duplicate content becomes major, but for newly launched websites that do not have any brand recognition or lots of inlinks, external duplicate content must be seen as toxic.

For more established webproperties it takes much longer until external duplicate content has a whole site negative impact. But external duplicate content pages are still practically useless from a SEO point of view.

Also, “first one wins” is the general rule, but it’s not guaranteed. If the content of a site is mostly external duplicate spam or rubbish, then even unique content first discovered on your site might not be seen as “your” content, as there is a high probability that you are not the authoritative source.

So what if we change or rearrange some words? This question is always asked when I talk about this topic. It does not matter, as soon as copy and paste are used in a paragraph of text it is a duplicate. On the contrary, if you read an article, rewrite it in your own words (without using copy paste) then this is, with a very high likelihood, not external duplicate content.

But, what about citations? If the external duplicate content is just a small part of the overall textual content, then don’t worry. The issue is mostly about “paragraphs of text content.” Again, there is no fixed percentage of how much is too much. Sorry to be vague but there are no precise answers here.

However, duplicate content does not apply to “structured content.” Structured content is anything and everything that is key-value pairs, definitions or tables. For example, addresses, telephone numbers, and recipe ingredients. For such structured, factual data there cannot really be an authoritative source, so they don’t contribute to external duplicate content.

There is no negative value in embedding external duplicate images, as images are usually duplicated, but it also has no positive value. It’s a lost opportunity if you embed soulless stock photos instead of showing some creativity (i.e. just use a picture you snapped with your mobile phone).

The conclusion out of all this: External duplicate content on your site has no or negative value for your webproperty. So don’t do it.

Now that we’ve discussed what external duplicate content is, we can return to point number six: A targeted page must host unique content or a unique collection of content. Unique content is the content produced when you are not duplicating external or internal content.

If you combine content - unique, external duplicate, internal duplicate, and structured content - in a new way, then we talk about the “unique combination of content.” Lists of data are fine if a user query asks for a list.

For example, [used cars liverpool] is almost certainly looking for a list of used cars (or used car dealerships) in Liverpool. Each list item probably consists of duplicate content, an item that is listed in full on some other page, regardless of whether is it on our site or external. Nonetheless, the list is a unique combination of the content itself.

Sometimes these unique combinations of content pages are not in the form of a list. Then we speak of aggregated detail pages, whereby the source of the aggregation can be external or internal. They might be intended to look like editorial articles (but really aren’t), often with multiple short paragraphs of text (so-called text-templates), datasheets or other techniques. Unique (or editorial) content and unique combinations of other content are often mixed on one page.

The major issue regarding a unique combination of content is always utility. If the page makes sense, if the search intent of the user gets fulfilled and if the user has a good user experience, then a unique combination of content is a valid and effective way to drive search traffic.

In my experience, some types of aggregation (for example, generating an article) are very, very hard to do right and very easy to do badly. Most aggregated detail pages are rubbish and must be seen as pure spam. Making sensemaking list pages is relatively easy. To be safe, always assure that point number four (a targeted page fulfills a presumed search intent) is always met.

7. A targeted page’s content has to fulfill predefined quality criteria (QC)

In addition to the page content being unique, it must also satisfy your predefined quality criteria (QC). It is vital you identify your QC, make sure it gets fulfilled during content creation, and always double check it.

Some parts of the QC are easily quantifiable, for example:

• a list should always have x number of items;
• a page must always have at least x pictures and y bullet points, or
• an address detail page must always display the address and telephone number.

But what about the QC that is harder to check? For instance, how do you make sure lists A and B are not the same lists (resulting in internal duplicate content)? With an editorial page QC is relatively easy to do, but with automated pages and potentially millions of targeted list pages, it’s significantly more challenging.

Just because it is hard does not mean you can skip this point. If you do not check for that, you will inadvertently create massive amounts of internal duplicate content.

8. A targeted page displays content and links visible without user interaction

Contrary to popular belief, Google does render CSS and execute JS. Google attempts to emulate what the user sees, but only what the user sees without clicking or touching counts as valuable content. Content hidden after any user interaction (other than scrolling) is usually devalued for Google and must be seen as wasted (this includes content in sliders, tabs, accordions, foldout questions and answers).

So, we must care about the design of the site and that all our valuable content is visible without user interaction, but we must also care about the HTML markup of the site. The HTML of the page should be coded so that Google can easily identify what the different parts of the page are about.

You cannot show the user one thing and Google something different.

Additionally, the first time visitor referred via Google, must be treated exactly as Google is treated. Everything else is called cloaking and is not a viable long term strategy. As soon as the user leaves the first page and moves within your site, you can do whatever you want as long as you are not misleading.

So if you choose to deliver a crappy second pageview user experience, your overall time on site and average pageviews will probably not be up to your competition, and you will not perform for long.

Note: Google used to only use IP addresses from the US and sent no language HTTP headers (Google was American and had no preferred language). That is no longer the (only) case, and so even web pages with geolocation and language detection features must now be renderable for Google. You must treat Google like any other first time visitor.

9. A targeted page only uses one language per page

One page, one language. If your targeted page mixes different languages on one page, it just will not perform. Your main content and your boilerplate (everything like navigation, teasers to other web pages, and other supplemental content) must be in the same language. For example, if your article is in German and your navigation is in English, then your page will always underperform.

Similar to the previous point, if you have major “other” language content in the markup of your page (even though it’s not visible on the page due to CSS and JS), this “other” language content will still hinder your performance in Google.

However, do not worry if you make a foreign language citation or have some foreign language terms within your content. There is no fixed percentage when something is too much. And do not confuse this with one website, one language. Having a multilanguage site is great, just don’t put more than one language on one page.

10. A targeted page should link to other targeted pages, and 11. A targeted page should be linked from at least one other targeted page

Every targeted page needs at least one link from another targeted page - and vice versa, every targeted page should link to other targeted pages. Pages that do not have a single site-internal link pointing to them do not perform. Pages that do not link to other pages are a one way street and only leave the user with the option to bounce back to Google.

You can either have a very sensemaking deliberate logic or simply use serendipity to achieve these goals. As we will see in “Best Practice #13: List of links to other targeted pages”, I recommend a mix of sensemaking and serendipity interlinking.

12. A targeted page must be listed in the sitemap.xml

Every targeted page must be distributed in a manageable, measurable and scalable way - in other words, every targeted page must be listed in your sitemap.xml. This is important, and we will discuss this topic in the “Distribution” chapter of this book.