Connect with us

SEO

Best Practices to Make It SEO-Friendly

Published

on

Best Practices to Make It SEO-Friendly

The increasing prevalence of React in modern web development cannot be ignored.

React and other similar libraries (like Vue.js) are becoming the de facto choice for larger businesses that require complex development where a more simplistic approach (like using a WordPress theme) won’t satisfy the requirements.

Despite that, SEOs did not initially embrace libraries like React due to search engines struggling to effectively render JavaScript, with content available within the HTML source being the preference.

However, developments in both how Google and React can render JavaScript have simplified these complexities, resulting in SEO no longer being the blocker for using React.

Still, some complexities remain, which I’ll run through in this guide.

On that note, here’s what we’ll cover:

But first, what is React?

React is an open-source JavaScript library developed by Meta (formerly Facebook) for building web and mobile applications. The main features of React are that it is declarative, is component-based, and allows easier manipulation of the DOM.

The simplest way to understand the components is by thinking of them as plugins, like for WordPress. They allow developers to quickly build a design and add functionality to a page using component libraries like MUI or Tailwind UI.

If you want the full lowdown on why developers love React, start here:

Rendering with React, a short history

React implements an App Shell Model, meaning the vast majority of content, if not all, will be Client-side Rendered (CSR) by default.

CSR means the HTML primarily contains the React JS library rather than the server sending the entire page’s contents within the initial HTTP response from the server (the HTML source).

It will also include miscellaneous JavaScript containing JSON data or links to JS files that contain React components. You can quickly tell a site is client-side rendered by checking the HTML source. To do that, right-click and select “View Page Source” (or CTRL + U/CMD + U).

Netflix's homepage source HTML

A screenshot of the netlfix.com homepage source HTML.

If you don’t see many lines of HTML there, the application is likely client-side rendering.

However, when you inspect the element by right-clicking and selecting “Inspect element” (or F12/CMD + ⌥ + I), you’ll see the DOM generated by the browser (where the browser has rendered JavaScript).

The result is you’ll then see the site has a lot of HTML:

Lots of HTML

Note the appMountPoint ID on the first <div>. You’ll commonly see an element like that on a single-page application (SPA), so a library like React knows where it should inject HTML. Technology detection tools, e.g., Wappalyzer, are also great at detecting the library.

Editor’s Note

Ahrefs’ Site Audit saves both the Raw HTML sent from the server and the Rendered HTML in the browser, making it easier to spot whether a site has client-side rendered content.

Gif showing Site Audit saves both Raw HTML and Rendered HTML

Even better, you can search both the Raw and Rendered HTML to know what content is specifically being rendered client-side. In the below example, you can see this site is client-side rendering key page content, such as the <h1> tag.

Gif showing site is client-side rendering key page content

Joshua Hardwick

Websites created using React differ from the more traditional approach of leaving the heavy-lifting of rendering content on the server using languages like PHP—called Server-side Rendering (SSR).

Flowchart showing the SSR process

The above shows the server rendering JavaScript into HTML with React (more on that shortly). The concept is the same for sites built with PHP (like WordPress). It’s just PHP being turned into HTML rather than JavaScript.

Before SSR, developers kept it even simpler.

They would create static HTML documents that didn’t change, host them on a server, and then send them immediately. The server didn’t need to render anything, and the browser often had very little to render.

SPAs (including those using React) are now coming full circle back to this static approach. They’re now pre-rendering JavaScript into HTML before a browser requests the URL. This approach is called Static Site Generation (SSG), also known as Static Rendering.

Two flowcharts showing the SSG process

In practice, SSR and SSG are similar.

The key difference is that rendering happens with SSR when a browser requests a URL versus a framework pre-rendering content at build time with SSG (when developers deploy new code or a web admin changes the site’s content).

SSR can be more dynamic but slower due to additional latency while the server renders the content before sending it to the user’s browser.

SSG is faster, as the content has already been rendered, meaning it can be served to the user immediately (meaning a quicker TTFB).

How Google processes pages

To understand why React’s default client-side rendering approach causes SEO issues, you first need to know how Google crawls, processes, and indexes pages.

We can summarize the basics of how this works in the below steps:

  1. Crawling – Googlebot sends GET requests to a server for the URLs in the crawl queue and saves the response contents. Googlebot does this for HTML, JS, CSS, image files, and more.
  2. Processing – This includes adding URLs to the crawl queue found within <a href> links within the HTML. It also includes queuing resource URLs (CSS/JS) found within <link> tags or images within <img src> tags. If Googlebot finds a noindex tag at this stage, the process stops, Googlebot won’t render the content, and Caffeine (Google’s indexer) won’t index it.
  3. Rendering – Googlebot executes JavaScript code with a headless Chromium browser to find additional content within the DOM, but not the HTML source. It does this for all HTML URLs.
  4. Indexing – Caffeine takes the information from Googlebot, normalizes it (fixes broken HTML), and then tries to make sense of it all, precomputing some ranking signals ready for serving within a search result.
Flowchart showing how Google crawls, processes, and indexes pages

Historically, issues with React and other JS libraries have been due to Google not handling the rendering step well.

Some examples include:

  • Not rendering JavaScript – It’s an older issue, but Google only started rendering JavaScript in a limited way in 2008. However, it was still reliant on a crawling scheme for JavaScript sites created in 2009. (Google has since deprecated the scheme.)
  • The rendering engine (Chromium) being out of date – This resulted in a lack of support for the latest browser and JavaScript features. If you used a JavaScript feature that Googlebot didn’t support, your page might not render correctly, which could negatively impact your content’s indexing.
  • Google had a rendering delay – In some cases, this could mean a delay of up to a few weeks, slowing down the time for changes to the content to reach the indexing stage. This would have ruled out relying on Google to render content for most sites.

Thankfully, Google has now resolved most of these issues. Googlebot is now evergreen, meaning it always supports the latest features of Chromium.

In addition, the rendering delay is now five seconds, as announced by Martin Splitt at the Chrome Developer Summit in November 2019:

Last year Tom Greenaway and I were on this stage and telling you, ‘Well, you know, it can take up to a week, we are very sorry for this.’ Forget this, okay? Because the new numbers look a lot better. So we actually went over the numbers and found that, it turns out that at median, the time we spent between crawling and actually having rendered these results is – on median – it’s five seconds!”

This all sounds positive. But is client-side rendering and leaving Googlebot to render content the right strategy?

The answer is most likely still no.

Common SEO issues with React

In the past five years, Google has innovated its handling of JavaScript content, but entirely client-side rendered sites introduce other issues that you need to consider.

It’s important to note that you can overcome all issues with React and SEO.

React JS is a development tool. React is no different from any other tool within a development stack, whether that’s a WordPress plugin or the CDN you choose. How you configure it will decide whether it detracts or enhances SEO.

Ultimately, React is good for SEO, as it improves user experience. You just need to make sure you consider the following common issues.

1. Pick the right rendering strategy

The most significant issue you’ll need to tackle with React is how it renders content.

As mentioned, Google is great at rendering JavaScript nowadays. But unfortunately, that isn’t the case with other search engines. Bing has some support for JavaScript rendering, although its efficiency is unknown. Other search engines like Baidu, Yandex, and others offer limited support.

Sidenote.

This limitation doesn’t only impact search engines. Apart from site auditors, SEO tools that crawl the web and provide critical data on elements like a site’s backlinks do not render JavaScript. This can have a significant impact on the quality of data they provide. The only exception is Ahrefs, which has been rendering JavaScript across the web since 2017 and currently renders over 200 million pages per day.

Introducing this unknown builds a good case for opting for a server-side rendered solution to ensure that all crawlers can see the site’s content.

In addition, rendering content on the server has another crucial benefit: load times.

Load times

Rendering JavaScript is intensive on the CPU; this makes large libraries like React slower to load and become interactive for users. You’ll generally see Core Web Vitals, such as Time to Interactive (TTI), being much higher for SPAs—especially on mobile, the primary way users consume web content.

Overview of metrics' performance, including FCP, LCP, etc

An example React application that utilizes client-side rendering.

However, after the initial render by the browser, subsequent load times tend to be quicker due to the following:

Depending on the number of pages viewed per visit, this can result in field data being positive overall.

Four bar graphs showing positive field data of FCP, LCP, FID, and CLS

However, if your site has a low number of pages viewed per visit, you’ll struggle to get positive field data for all Core Web Vitals.

Solution

The best option is to opt for SSR or SSG mainly due to:

  • Faster initial renders.
  • Not having to rely on search engine crawlers to render content.
  • Improvements in TTI due to less JavaScript code for the browser to parse and render before becoming interactive.

Implementing SSR within React is possible via ReactDOMServer. However, I recommend using a React framework called Next.js and using its SSG and SSR options. You can also implement CSR with Next.js, but the framework nudges users toward SSR/SSG due to speed.

Next.js supports what it calls “Automatic Static Optimization.” In practice, this means you can have some pages on a site that use SSR (such as an account page) and other pages using SSG (such as your blog).

The result: SSG and fast TTFB for non-dynamic pages, and SSR as a backup rendering strategy for dynamic content.

Sidenote.

You may have heard about React Hydration with ReactDOM.hydrate(). This is where content is delivered via SSG/SSR and then turns into a client-side rendered application during the initial render. This may be the obvious choice for dynamic applications in the future rather than SSR. However, hydration currently works by loading the entire React library and then attaching event handlers to HTML that will change. React then keeps HTML between the browser and server in sync. Currently, I can’t recommend this approach because it still has negative implications for web vitals like TTI for the initial render. Partial Hydration may resolve this in the future by only hydrating critical parts of the page (like ones within the browser viewport) rather than the entire page; until then, SSR/SSG is the better option.

Since we’re talking about speed, I’ll be doing you a disservice by not mentioning other ways Next.js optimizes the critical rendering path for React applications with features like:

  • Image optimization – This adds width and height <img> attributes and srcset, lazy loading, and image resizing.
  • Font optimization – This inlines critical font CSS and adds controls for font-display.
  • Script optimization – This lets you pick when a script should be loaded: before/after the page is interactive or lazily.
  • Dynamic imports – If you implement best practices for code splitting, this feature makes it easier to import JS code when required rather than leaving it to load on the initial render and slowing it down.

Speed and positive Core Web Vitals are a ranking factor, albeit a minor one. Next.js features make it easier to create great web experiences that will give you a competitive advantage.

TIP

Many developers deploy their Next.js web applications using Vercel (the creators of Next.js), which has a global edge network of servers; this results in fast load times.

Vercel provides data on the Core Web Vitals of all sites deployed on the platform, but you can also get detailed web vital data for each URL using Ahrefs’ Site Audit.

Simply add an API key within the crawl settings of your projects.

Text field to add API key

After you’ve run your audit, have a look at the performance area. There, Ahrefs’ Site Audit will show you charts displaying data from the Chrome User Experience Report (CrUX) and Lighthouse.

Pie charts and bar graphs showing data from CrUX and Lighthouse

2. Use status codes correctly

A common issue with most SPAs is they don’t correctly report status codes. This is as the server isn’t loading the page—the browser is. You’ll commonly see issues with:

  • No 3xx redirects, with JavaScript redirects being used instead.
  • 4xx status codes not reporting for “not found” URLs.

You can see below I ran a test on a React site with httpstatus.io. This page should obviously be a 404 but, instead, returns a 200 status code. This is called a soft 404.

Table showing URL on left. On right, under "Status codes," it shows "200"

The risk here is that Google may decide to index that page (depending on its content). Google could then serve this to users, or it’ll be used when evaluating a site.

In addition, reporting 404s helps SEOs audit a site. If you accidentally internally link to a 404 page and it’s returning a 200 status code, quickly spotting the area with an auditing tool may become much more challenging.

There are a couple of ways to solve this issue. If you’re client-side rendering:

  1. Use the React Router framework.
  2. Create a 404 component that shows when a route isn’t recognized.
  3. Add a noindex tag to “not found” pages.
  4. Add a <h1> with a message like “404: Page Not Found.” This isn’t ideal, as we don’t report a 404 status code. But it will prevent Google from indexing the page and help it recognize the page as a soft 404.
  5. Use JavaScript redirects when you need to change a URL. Again, not ideal, but Google does follow JavaScript redirects and pass ranking signals.

If you’re using SSR, Next.js makes this simple with response helpers, which let you set whatever status code you want, including 3xx redirects or a 4xx status code. The approach I outlined using React Router can also be put into practice while using Next.js. However, if you’re using Next.js, you’re likely also implementing SSR/SSG.

3. Avoid hashed URLs

This issue isn’t as common for React, but it’s essential to avoid hash URLs like the following:

  • https://reactspa.com/#/shop
  • https://reactspa.com/#/about
  • https://reactspa.com/#/contact

Generally, Google isn’t going to see anything after the hash. All of these pages will be seen as https://reactspa.com/.

Solution

SPAs with client-side routing should implement the History API to change pages.

You can do this relatively easily with both React Router and Next.js.

4. Use <a href> links where relevant

A common mistake with SPAs is using a <div> or a <button> to change the URL. This isn’t an issue with React itself, but how the library is used.

Doing this presents an issue with search engines. As mentioned earlier, when Google processes a URL, it looks for additional URLs to crawl within <a href> elements.

If the <a href> element is missing, Google won’t crawl the URLs and pass PageRank.

Solution

The solution is to include <a href> links to URLs that you want Google to discover.

Checking whether you’re linking to a URL correctly is easy. Inspect the element that internally links and check the HTML to ensure you’ve included <a href> links.

As in the above example, you may have an issue if they aren’t.

However, it’s essential to understand that missing <a href> links aren’t always an issue. One benefit of CSR is that when content is helpful to users but not search engines, you can change the content client-side and not include the <a href> link.

In the above example, the site uses faceted navigation that links to potentially millions of combinations of filters that aren’t useful for a search engine to crawl or index.

List of genres

Loading these filters client-side makes sense here, as the site will conserve crawl budget by not adding <a href> links for Google to crawl.

Next.js makes this easy with its link component, which you can configure to allow client-side navigation.

If you’ve decided to implement a fully CSR application, you can change URLs with React Router using onClick and the History API.

5. Avoid lazy loading essential HTML

It’s common for sites developed with React to inject content into the DOM when a user clicks or hovers over an element—simply because the library makes that easy to do.

This isn’t inherently bad, but content added to the DOM this way will not be seen by search engines. If the content injected includes important textual content or internal links, this may negatively impact:

  • How well the page performs (as Google won’t see the content).
  • The discoverability of other URLs (as Google won’t find the internal links).

Here’s an example on a React JS site I recently audited. Here, I’ll show a well-known e‑commerce brand with important internal links within its faceted navigation.

However, a modal showing the navigation on mobile was injected into the DOM when you clicked a “Filter” button. Watch the second <!—-> within the HTML below to see this in practice:

Gif of modal showing the navigation on mobile was injected into DOM

Solution

Spotting these issues isn’t easy. And as far as I know, no tool will directly tell you about them.

Instead, you should check for common elements such as:

  • Accordions
  • Modals
  • Tabs
  • Mega menus
  • Hamburger menus

You’ll then need to inspect the element on them and watch what happens with the HTML as you open/close them by clicking or hovering (as I have done in the above GIF).

Suppose you notice JavaScript is adding HTML to the page. In that case, you’ll need to work with the developers. This is so that rather than injecting the content into the DOM, it’s included within the HTML by default and is hidden and shown via CSS using properties like visibility: hidden; or display: none;.

6. Don’t forget the fundamentals

While there are additional SEO considerations with React applications, that doesn’t mean other fundamentals don’t apply.

You’ll still need to make sure your React applications follow best practices for:

Final thoughts

Unfortunately, working with React applications does add to the already long list of issues a technical SEO needs to check. But thanks to frameworks like Next.js, it makes the work of an SEO much more straightforward than what it was historically.

Hopefully, this guide has helped you better understand the additional considerations you need to make as an SEO when working with React applications.

Have any questions on working with React? Tweet me.




Source link

SEO

Keyword Mapping. A Practical Guide for the Curious

Published

on

Keyword Mapping. A Practical Guide for the Curious

Deciding whether a keyword should be targeted by a separate page or clustered with other keywords is a common problem in SEO. Keyword mapping is a process aimed at solving this.

Keyword mapping is popularly defined as assigning keywords to pages. But what you really need to solve the problem is assigning topics to content types

In this article, I’ll explain the benefits of this approach and, more importantly, I’ll show you the process. No templates required.

Benefits of keyword mapping (the alternative way) 

Fact 1. Google may see seemingly different keywords as the same topic.

For example, we rank for these keywords in the top 10 with a single page: 

  • seo basics”
  • how to use seo” 
  • beginner’s guide to seo”
  • getting started with seo”
  • seo knowledge”

Fact 2. Conversely, Google may see seemingly similar keywords as different topics. 

For example, let’s compare “digital marketing” with “online marketing.” I’d say those two keywords are pretty close to each other. Google disagrees. 

Low SERP similarity score signals potentially different topics
Everywhere you look, the same story. Top-ranking pages and our SERP similarity score (100-point scale; the more, the higher similarity) say that these are completely different topics SEO-wise.

The above two facts are also reasons why keyword mapping by just relying on keywords is not the optimal way. You won’t know whether you’re wasting your time targeting the same topic with different keywords or just “confusing” Google. 

But why content types instead of pages or even URLs? Because before you decide what page will be used to target the keyword, you’ll need to identify the search intent of the keyword. And a good starting point for that is identifying the dominating type of content on the first page of Google. 

To sum up, the benefits of keyword mapping using topics and content types are: 

  • Seeing keywords the same way Google sees them: as topics and subtopics. 
  • Incorporating search intent into the process. 
  • Keeping an organized list of topics, which also helps to prevent duplicating content.

Note

Keyword mapping can’t substitute keyword research. While keyword mapping is basically a form of organizing keywords, keyword research provides you the keywords and the confidence that: 

  • Your keywords have traffic potential.
  • You can match the search intent behind your keywords.
  • Your keywords will bring valuable traffic. 
  • You can rank for those keywords. 

Learn how to choose the right keywords with our full guide.

Going further, we’ll look at two levels of using this method: the fast lane and the more thorough one. 

Learn more: What Is Semantic Search? How It Impacts SEO 

Level 1 – Fast, reasonable job

You’ll need a keyword research tool that can do keyword grouping based on what’s on the SERP, such as Ahrefs’ Keywords Explorer. In the case of this tool: 

  1. Enter your keywords
  2. Open Matching terms report
  3. Go to the Parent topics tab 
Three steps to find Parent Topics via Keywords Explorer

If you click on a Parent Topic, you will find separate topics “distilled” from your keywords. So for example, you will see keywords like “can babies get covid” and “babies and covid” grouped under the same topic. 

Keywords grouped under the same Parent Topic

Sidenote.

To identify the Parent Topic, we take the #1 ranking page for your keyword and find the keyword responsible for sending the most traffic to that page.

At this level of keyword mapping, your target keyword is the Parent Topic (not the keywords inside that Parent Topic). 

The next step is to identify the content type. The easiest way to do this is to see what kind of content dominates the first three to five results in Google. 

Typical content types are:

  • Articles
  • Videos
  • Product pages
  • Product category pages
  • Landing pages 
Top-ranking pages with a dominating content type
For example, the dominating content type for “teething symptoms” is the article.

As a result, assigning topics to content types will give you a super simple yet highly actionable database.

Topic Content type
Teething symptoms Article
When do babies roll over Article
Baby formula Mixed (product pages on top)
When can babies have water Article

Sidenote.

What about secondary keywords or supporting keywords? We recommend picking them in the content creation phase as subtopics needed to cover a topic in full. Learn a few ways you can find them here.

So this is the fast method. The great thing about it is that it automates keyword grouping by using real SERP data (and not just semantics). 

However, it has its downsides too. Sometimes, it “hides” less popular topics that could potentially be targeted with a separate page. Here’s why. 

The parent keyword is derived from the top-ranking page on the SERP. If Google thinks that the best answer to the query is found on a page that is targeting a broader topic, it will still use it. This may result in a confusing SERP like this one: 

Confusing SERP example
The top result is a featured snippet taken from a page with a broader topic. Hence, the Parent Topic (here seen as “Top keyword”) in Ahrefs. But pretty much every other page on the SERP targets the keywords directly.

This kind of situation probably won’t happen too often. But if you want to squeeze everything out of your keyword mapping process, you need to go to level 2. 

Level 2 – Thorough but time consuming

In level 2, we’re going to take a closer look at the Parent Topics to see what’s in them. 

  1. First, you should pick a Parent Topic.
  2. Sort keywords inside the topic by KD (Keyword Difficulty). Big differences in KD will be an indication of a different set of pages on the SERP.
  3. If you see a keyword with a significantly different KD than the Parent Topic, click on the SERP button.
  4. See if the top-ranking pages, excluding the first result, talk about the keyword instead of the Parent Topic. You can use the Compare with feature for a quick overview of the situation. The lower the SERP similarity score, the higher the probability you’re looking at two different topics. 
How to investigate Parent Topics

Let’s look at a couple of examples. 

In the first example, we’ve got a keyword with a KD score that’s 20 higher than the Parent Topic. Upon investigating, we see that we may be dealing with two separate topics: The SERP similarity is quite low. Also, there is only one common result, while other pages target the keyword directly. 

Keywords grouped under the same topic but have dissimilar SERPs

Next example. Here we have “teething symptoms” (KD 65) and “when do babies get molars” (KD 28). Looking at SERP similarity, we see that this, again, may be a case of two topics. 

Low SERP similarity between two keywords

But there’s more. Only the bottom results target the keyword directly. Others talk about teething timelines, stages, charts, etc. This is a hint for yet another way to rank for the keyword. 

Only bottom results target the keyword directly

Generally speaking, when you see that you’re dealing with a separate topic “in disguise,” the decision comes down to:

  1. Targeting the Parent Topic anyway. For example, if the top result is a featured snippet, you may be able to win it with a page on a relevant broader topic. 
  2. Marking the keyword as a separate topic and targeting it directly with a separate page. In this case, add that keyword as a topic to target and note down the content type. 
  3. Turning to SERP analysis in tougher cases (like our example above). 

Final thoughts 

Feel free to customize the process and add your own data points. If you feel like going a step further and assigning URLs, your website folders, or introducing some kind of prioritization (e.g., business potential), this won’t hurt. 

However, keep in mind that keyword mapping is not a good way to design your entire website structure. Most often than not, not all pages on your site should be search-based. 

What are the next steps after keyword mapping? 

Got comments or questions? Ping me on Twitter or Mastodon



Source link

Continue Reading

SEO

Everything You Need To Know

Published

on

Of all the many, many functions available in Google Ads, I have a few that are my favorites. And sitelink assets – previously known as sitelink extensions – are at the top of my list.

Why? Because they’re so versatile. You can do almost anything with them if you think through your strategy carefully.

For example, you can use the mighty sitelink in your advertising to:

  • Promote low search volume themes.
  • Push lagging products out the door.
  • Maximize hot sellers.
  • Highlight certain product categories.
  • Answer common questions.
  • Handle PR problems.

And that’s just a start! Sitelink assets can almost do it all.

Best Practices For Using Sitelink Assets Extensions

If you truly want to get the most out of your sitelinks, you need to think about your intention.

To help you with that, I’m going to lay out a few sitelink guidelines.

1. Get clear on your objectives. Before you start, you need to think about your goals. What are you trying to achieve with these assets? Are you advertising products or services? Will the asset work well with both branded and non-branded keywords? Your answers to these questions will help determine if your sitelinks are versatile and useful to the searcher.

2. Use sitelinks as part of your larger strategy. Don’t think of your sitelinks in isolation. You should also consider the accompanying ad, landing page, and other assets. Make sure they all work together in service to your overarching strategy.

3. Use a mix of sitelinks. Sitelinks can serve multiple purposes, so make sure you’re using a variety. For example, you don’t want to use every sitelink on an ad to promote on-sale products. Instead, use a mix. One could promote an on-sale product, one could generate leads, one could highlight a new product category, and one could direct prospective clients to useful information.

4. Create landing pages for your sitelinks. Ideally, you want to send users to landing pages that tightly correlate with your sitelink instead of just a regular page on your website.

5. Track sitelink performance and adjust. It’s not enough to set up sitelinks. You should also track them to see which links are getting traction and which ones are not. This doesn’t mean that all sitelinks should perform equally (more on this below), but it does mean they should perform well given their type and objectives.

Why it’s Better To Use A Mix Of Sitelink Assets

Let’s dive deeper into this idea of using a mix of sitelinks by looking at an example.

In a new client account, we created four different types of sitelinks:

  • Two sitelinks are product-focused (as requested by the client).
  • One sitelink connects users with an engineer to learn more about the product (“Speak to an Engineer”). It has more of a sales focus.
  • One sitelink allows users to learn more about the products without speaking to an engineer (“What is?”).

The “What is?” sitelink is outperforming the “Speak to an Engineer” sitelink when we measure by CTR. While we need more data before making any changes, I predict we’ll eventually swap out the sales-y “Speak to an Engineer” sitelink for something else.

The fact that the educational link (“What is?”) is performing better than the sales-y link (“Speak to an Engineer”) isn’t too surprising in this case. The product is a new, cutting-edge robot that not many people are aware of, yet. They want more info before talking to someone.

Screenshot by author, January 2023

By using a mix of sitelinks, and assessing the performance of each, we gained a lot of valuable information that is helping to guide our strategy for this account. So going with a mix of sitelinks is always a good idea. You never know what you’ll discover!

Sitelink Assets Examples

Now, let’s look at some specific examples of sitelink assets in Google Ads.

Example 1: Chromatography

Sitelinks extension - Chromatography exampleScreenshot from Google, January 2023

Application Search: This ad is for a highly technical product that can be used in a wide variety of applications. (Chromatography is a laboratory technique for separating mixtures.) So putting “application search” in a sitelink here might make sense. It helps prospective clients find what they’re looking for.

Sign up and Save Big: A good sitelink for lead generation and potential revenue.

Technical Support: I’m not a big fan of putting technical support in sitelinks. Tech support seems more targeted to current users rather than prospective users. But who knows, maybe they really do want to help current users get tech support via their advertising.

Guides and Posters: Again, this sitelink is a bit unusual, but it might be appropriate for this product. Perhaps people are downloading branded posters and posting them in their workplaces. If so, it’s a great way to build brand awareness.

Example 2: Neuroscience Courses

Sitelink Extensions - Nueroscience courses exampleScreenshot from Google, January 2023

I love everything about these sitelinks! The advertising is using them to reach people in all phases of the buyer journey.

For people not ready to commit:

  • Study Neuroscience: This sitelink is broad and informational. It’s helpful to people who have just started to explore their options for studying neuroscience.
  • Get Course Brochure: This sitelink is also great for people in the research phase. And while we mostly live in an online world, some people still prefer to consume hard-copy books, brochures, etc. With this sitelink, the school is covering its bases.

For people getting close to committing:

  • Online Short Course: This is the course the school offers. It’s a great sitelink for those almost ready to sign up.

For people ready to sign up:

  • Register Online Now: This is the strongest call to action for those ready to commit. It takes people directly to the signup page.

Example 3: Neuroscience Degrees

Let’s look at another example from the world of neuroscience education: this time for a neuroscience degree program.

Sitelink extensions - neuroscience degree exampleScreenshot from Google, January 2023

In contrast to the previous two examples, the sitelinks in this ad aren’t as strong.

Academics Overview: This sitelink seems more appropriate for a broad term search, such as a search on the school’s name. If the searcher is looking for a specific degree program (which seems like the intention based on the term and the ad), the sitelinks should be something specific to that particular degree program.

Scholarships: Just as with the above sitelink, “Scholarships” doesn’t seem very helpful either. The topic of scholarships is important—but probably doesn’t need to be addressed until the person determines that this school is a good fit.

Example 4: Code Security

Next, let’s look at two Google search ads for code security products.

Sitelink extensions - code security exampleScreenshot from Google, January 2023

 

The sitelinks in these two ads look like typical assets you’d find for SaaS, cloud-based, or tech companies. They click through to a lot of helpful information, such as product plans and success stories.

I particularly like the Most Common Risks sitelink in the second ad. It leads to a helpful article that would be great for engaging top-of-funnel leads.

On the flip side, I’m not a big fan of the Blog sitelink in the first ad. “Blog” simply isn’t very descriptive or helpful.

Still, there are no right or wrong sitelinks here. And it would be interesting to test my theory that blog content is not a top-performing asset!

Sitelink Assets Are More Than An Afterthought

I hope I’ve convinced you of the usefulness and versatility of sitelinks when created with specific objectives that align with your broader strategy.

So don’t create your sitelink assets as an afterthought.

Because if you give them the careful consideration they deserve, they’ll serve you well.

Note: Google sitelink assets were previously known as sitelink extensions and renamed in September 2022.

More resources:


Featured Image: Thaspol Sangsee/Shutterstock



Source link

Continue Reading

SEO

AI Content In Search Results

Published

on

AI Content In Search Results

Google has released a statement regarding its approach to AI-generated content in search results.

The company has a long-standing policy of rewarding high-quality content, regardless of whether humans or machines produce it.

Above all, Google’s ranking systems aim to identify content that demonstrates expertise, experience, authoritativeness, and trustworthiness (E-E-A-T).

Google advises creators looking to succeed in search results to produce original, high-quality, people-first content that demonstrates E-E-A-T.

The company has updated its “Creating helpful, reliable, people-first content” help page with guidance on evaluating content in terms of “Who, How, and Why.”

Here’s how AI-generated content fits into Google’s approach to ranking high-quality content in search results.

Quality Over Production Method

Focusing on the quality of content rather than the production method has been a cornerstone of Google’s approach to ranking search results for many years.

A decade ago, there were concerns about the rise in mass-produced human-generated content.

Rather than banning all human-generated content, Google improved its systems to reward quality content.

Google’s focus on rewarding quality content, regardless of production method, continues to this day through its ranking systems and helpful content system introduced last year.

Automation & AI-Generated Content

Using automation, including AI, to generate content with the primary purpose of manipulating ranking in search results violates Google’s spam policies.

Google’s spam-fighting efforts, including its SpamBrain system, will continue to combat such practices.

However, Google realizes not all use of automation and AI-generated content is spam.

For example, publishers automate helpful content such as sports scores, weather forecasts, and transcripts.

Google says it will continue to take a responsible approach toward AI-generated content while maintaining a high bar for information quality and helpfulness in search results.

Google’s Advice For Publishers

For creators considering AI-generated content, here’s what Google advises.

Google’s concept of E-E-A-T is outlined in the “Creating helpful, reliable, people-first content” help page, which has been updated with additional guidance.

The updated help page asks publishers to think about “Who, How, and Why” concerning how content is produced.

“Who” refers to the person who created the content, and it’s important to make this clear by providing a byline or background information about the author.

“How” relates to the method used to create the content, and it’s helpful to readers to know if automation or AI was involved. If AI was involved in the content production process, Google wants you to be transparent and explain why it was used.

“Why” refers to the purpose of creating content, which should be to help people rather than to manipulate search rankings.

Evaluating your content in this way, regardless of whether AI-generated or not, will help you stay in line with what Google’s systems reward.


Featured Image: Alejandro Corral Mena/Shutterstock



Source link

Continue Reading

Trending

en_USEnglish