The Internet Marketing Driver

Web Stories Powered by AMP – 12 Tips and Recommendations For Creating Your First Story

By Leave a Comment

I’ve been following the progression of Web Stories (formerly called AMP stories) since 2018 when the developer preview launched, and they have been hard to ignore recently. Google has been pushing the Story format pretty hard over the past year and I’ve seen stories show up more and more both in Search and in Discover.

If you aren’t familiar with Web Stories, they are immersive AMP experiences that let publishers cover a topic over multiple pages or screens. It’s similar to the stories format you’re familiar with across social networks like Instagram, Snapchat, and Facebook.

Here are screenshots of the Web Story I created. The first image is the story on desktop and the second image shows the story on mobile:

From a visibility standpoint, Web Stories can rank just like any other web pages and you will also get a nifty story icon in the mobile search results. I’ll cover more about the ranking effect of stories later in the post.

Jumping in and building my first Web Story, powered by AMP:
Based on Google’s recent focus on Web Stories, I decided to learn more about the format and publish one of my own. So, last week I chose a topic I had researched heavily (Google’s Disqus indexing bug) and dove in head-first. I published that story and shared it across social media accounts. It definitely piqued the curiosity of many SEOs and ended up driving quite a bit of traffic (it still is actually). More about that soon.

If you’re interested in seeing what a Web Story looks like now, you can check out my story about the Disqus indexing problem. If you’re already familiar with how Web Stories work, then you can continue below.

After developing and publishing the story, there were some important points, tips, and recommendations I thought could help others looking to get involved with Web Stories. So I compiled a list of 12 tips and recommendations in this post.

The information below spans a number of topics from creative strategy to technical execution to tracking to Search visibility. I do believe we’ll start seeing more and more Web Stories across surfaces and I hope my tips are helpful as you start to explore stories for your own projects!

Web Stories: 12 Tips for building your first story.

1. Story Creation: It’s a process…
When I sat down to map out my first Web Story, it was clear it wouldn’t be a quick process. It reminded me of developing multimedia applications, or a video production, since there was a lot involved during the planning stages. For example, storyboarding the various screens, mapping out visual assets that would be needed, determining audio and video components that would support the story, and more.

I love working on that type of project (based on heavily working in that niche earlier in my career), but it’s important to understand that building a Web Story is not a ten-minute project. It’s a process that will take some time if you’re going to do it right.

Planning is critically important or you can end up spending enormous amounts of time on areas that aren’t impactful.  Topic-wise, my recommendation is to cover a very specific topic with each story (and one you are extremely familiar with).

2. Storyboard First: Don’t skip this critically important step.
I mentioned earlier that a storyboard was necessary. If you haven’t storyboarded a video or multimedia application, it’s essentially a plan of what will be covered step-by-step (or page by page for Web Stories). That includes the copy, visuals, animation, audio, and video for each page in the story.

Once you map out a solid storyboard, you can start designing and developing based on that plan. Having a strong storyboard can make it much easier to execute than “riffing” through each page (designing, writing, and building on the fly).

When building a storyboard, you can sketch out the screens by hand or use software to help you map out each page in your story. You can even use PowerPoint or Google Slides to storyboard your Web Story if you want. It’s not about the technology, it’s more about having each page planned before digging in. I find sketching out the screens works well for me.

Here is what a storyboard looks like. And note, my sketches are definitely not as good as what you are seeing in the photo! It’s more about mapping out your production and not being an amazing artist. :)

BTW, Masterclass has a blog post featuring Jodi Foster that covers storyboards (for video). You can check that out for more information and tips about creating them.

3. Photoshop is your friend. No… it’s your core weapon in the game of Web Stories.
The visual nature of Web Stories means you’ll need killer visuals. And that typically means you’ll be working in Photoshop heavily (or some type of image editing application). While developing my story, I found myself combining, masking, layering, and adjusting images to get the right visuals.

In Web Stories, you can use background images and then layer other images (with transparency if needed). You can also use animated gifs to provide more effect. Regardless, you’ll be working with images heavily.

The core point is that you should be comfortable editing images in an application like Photoshop. It will be your best friend throughout the process of building your story. And it can make a huge difference in the impact that your story has with users.

4. Multimedia for supporting your Web Story, including video, audio, and animation.
Web Stories provide an immersive AMP experience and support video, audio, and animation. Multimedia elements like this can add a powerful component to your stories that enable users to experience your topic on another level. You can check the AMP documentation for the various AMP components that are supported.

But, there’s a fine balance between providing supporting multimedia components and overwhelming your users with unnecessary distractions. I recommend testing various multimedia assets locally and in your staging environment. Have other people go through your story while you’re developing it. You might find certain elements are over-the-top, while others really pack an exciting punch.

Remember, multimedia should support your story and not distract users from the story. In my first story, I added a subtle video of typing a comment in Disqus (that questions whether the comment will be indexed):

5. Know Your (HTML) Tags
Web Stories (like other AMP urls) support a subset of html tags. This is important to understand as you plan and build your story. You can review those tags, and more, in the AMP html specification in the developer documentation. Also, some html tags should be replaced with specific amp tags (like image, video, audio, etc.)

Also, you can style your Web Story elements via CSS (up to a 75K limit for your CSS, whether the styles are provided inline or via linked stylesheets).

And from a linking standpoint, I’ve received a lot of questions about adding links to external content from within a story. Yes, you can definitely do that and I included two links in my first story to supporting content.

6. Story Execution: Code first, use tools later.
There are several story creation tools on the market, but I recommend hand coding your first Web Story. By coding your story, you can learn a lot about how Web Stories work, the code running each story, how the setup works, and more. This will also help you debug stories in the future that aren’t behaving correctly in production.

After you learn more about how Stories are actually coded, you might check out various story builders. I haven’t tried many third-party tools for Web Stories yet, but there is an official WordPress plugin in beta that looks pretty cool. The AMP team announced that a few weeks ago. If you’re brave, you can install it now and play around. That said, I still recommending hand coding your first Web Story! :)

7. Web Stories Are Device Agnostic: They work on both desktop and mobile.
Since Stories are AMP-based, many people think they are just for mobile. That’s not true. Web Stories run on desktop as well! You can upload Stories to your server just like any other webpage and they can be accessed directly by users and by Google.

You will definitely want to test out your Web Story across both desktop and mobile to make sure everything looks good and works properly. You can’t guarantee that users will just be arriving via mobile, so thoroughly test your story across browsers, operating systems, and devices.

Here is a screenshot of my Disqus Web Story running on desktop:

8. Speed: Web Stories are served from the AMP cache.
Since Stories are AMP-based, you can leverage the AMP cache for lightning-fast delivery. As long as they are valid AMP urls, Google can add your Story to the AMP cache. Once it’s cached, that version of your story will be served via the AMP cache in the mobile search results.

Google’s AMP cache enables your AMP urls and Stories to load near-instantly (an important benefit of running AMP).

9. Tracking Stories: Don’t forget analytics!
You will definitely want to track your Web Stories, so make sure to include the necessary tracking scripts. To start, I would focus on just getting basic Google Analytics tracking implemented and then you can expand from there (to include advanced tracking throughout your Web Story).

Note, I definitely ran into some initial challenges with getting GA tracking to work, but ultimately did get it to work… Also, I used Google Tag Manager and it was a little tricky to set up. But again, it is tracking well now (at least basic tracking). I plan to expand that soon.

10. Rankings: Can Web Stories rank? Yes, they can, and across surfaces.
Over the past year, I’ve seen Web Stories show up more and more in the search results. Also, Google can display a Visual Stories carousel in the search results. So yes, Web Stories can rank.

And when your stories rank, your listing receives an image thumbnail in the mobile SERPs, along with a nifty Web Story icon. Both can help your story gain attention and can help drive stronger click through rates from the mobile SERPs.

Here is my web story ranking in the desktop search results and you can check previous screenshots in this post to see it ranking on mobile.

In Google Search Console (GSC), you can track stories just like any other urls in the performance reporting. You can see queries that users searched for that yielded your story in the SERPs, and you can see impressions, clicks, position, and click through rate. Also, there is an AMP Story filter in GSC where you can isolate your Web Stories.

Also, Web Stories can show up in Google Discover and there is dedicated reporting for Discover in GSC. That’s a good segue to my next tip…

11. Web Stories in Google Discover: A hidden weapon for publishers (at least for now).
Over the past year, I have noticed more Web Stories showing up in Google Discover. Actually, I shared that on Twitter several times and explained it was a huge opportunity for publishers that are early adopters of the format. Here’s my tweet from February after seeing Web Stories show up in Discover:

And here is what a Web Story looks like in the Discover feed. Notice the larger image in the feed (with a 3×4 aspect ratio):

Well, after publishing my own story, I think I was right. My Web Story has gained over 304K impressions since being published last week. So, Google is pushing out stories hard in the Discover feed (for sites that have earned their spot in the feed).

Although the story has driven over 800 clicks from Discover in the last week, the click through rate has been relatively low (compared to Discover stats across publishers I’m helping). I’m not sure if that’s the narrow focus of the story, how it looks in the feed, where it’s placed in the feed, etc. That’s tough to figure out since you can’t see exactly how others are seeing your story in their own Discover feed. For example, the story could be in a carousel of stories, stand-alone in the feed (which can yield larger images), it could be ranking lower in their feed, etc.

I’ll be testing out more stories soon to see how they perform over time. Regardless, if you’re a publisher looking to gain more Discover visibility, you should definitely check out Web Stories.

Note, Google just updated its help document for Google Discover and provided more information about how content appears in the feed. Kenichi Suzuki found that the other day and tweeted the update.

As Kenichi pointed out, Google now mentions expertise, authoritativeness, and trust (E-A-T) in that document. For example, “Our automated systems surface content in Discover from sites that have many individual pages that demonstrate expertise, authoritativeness and trustworthiness (E-A-T).” That’s important to understand for Discover (and for Search in general).

So again, if you’re eligible to show in Discover, and you have earned your spot in someone’s feed, then Web Stories can provide a powerful Discover listing. And it seems Google is pushing more stories in the Discover feed based on what I’ve seen over the past year.

In addition, Google recently began testing a Web Stories carousel in Discover. I haven’t seen that yet in my feed, but it shows that Google is experimenting heavily with stories in Discover. This is all important for publishers looking to gain more visibility.

12.  Web Story Content Strategy
I could write an entire post on this topic, but I wanted to quickly bring it up now. When planning your Web Stories, it’s important to figure out your content strategy per story. There are several paths you can take. For example, will your Stories be stand-alone projects, will they be combined with another post, will you repurpose other articles into stories, will you be covering events as Web Stories, etc.?

On that note, Web Stories support live stories, which enable you to cover live events. It’s just an example of the various ways that Web Stories can be utilized.

The sky’s the limit creativity-wise, but that can also be overwhelming. I recommend testing out various approaches and see what works best for your situation. Experimentation is key and you might be surprised with what works best.

Summary: Web Stories, a new immersive format powered by AMP
If you are interested in testing the waters with Web Stories, then I hope the various tips and recommendations I provided were helpful. Again, Google seems to be pushing Web Stories hard and they can rank well in both Search and Discover.

In my opinion, it’s definitely worth testing out stories for your own site. But as I explained earlier, it’s not a ten-minute project… it’s definitely a process. I recommend taking a focused approach to building your first Web Story. Map it out, storyboard it, and hand code it. You never know, when it’s all said and done, you might have a good story to tell. :)

GG

Visualizing The SEO Engagement Trap – How To Use Behavior Flow In Google Analytics To View User Frustration [Case Study]

By Leave a Comment

When thinking about content quality, it’s incredibly important to meet or exceed user expectations based on query. If your content cannot do that, then users can end up extremely frustrated as they search Google, click through your listing in the search results, scan your page, and not find what they were looking for. And that can lead to all sorts of problems SEO-wise.

When you don’t meet or exceed user expectations, one possible result is a user jumping back to the search results to find another solution (low dwell time). That’s clearly not what you want, but beyond the jump back to the SERPs, there are also times users stay on the site and keep digging believing they can ultimately find what they were looking for. That’s a classic engagement trap where users can end up running around a site visiting page after page without finding what they were looking for.

From a broad core algorithm update standpoint, Google is not going to react well over time when sites frustrate users and cannot provide answers that meet or exceed user expectations. We’ve seen that time and time again when broad core ranking updates roll out. In addition, I’ve seen this for a very long time with major algorithm updates overall, including during medieval Panda days.

As I’ve said many times before while writing about major algorithm updates, “Hell hath no fury like a user scorned”. In other words, don’t frustrate your users or bad things can happen during major Google algorithm updates.

This sounds logical, but how you can show a site owner user frustration like I explained above? For example, real data showing that users are frustrated versus just providing your opinion. Well, I surfaced a great example recently and I’m going to share more about that below. It’s something you can do for your own site and you can accomplish this using a tool that’s freely available and right under your nose – Google Analytics.

Backing Up SEO Intuition With Data – Visualizing User Frustration
I’m helping a site now that has been negatively impacted by two broad core updates in a row. I started helping them in April after they reached out to me about being hit by the January 2020 Core Update. Then as I was auditing the site, and they were making changes, the site was hit a second time during the May 2020 Core Update.

Remember, recent changes will typically not be taken into account with broad core updates and the site was just in the beginning stages of implementing changes. You can read my latest post about the May 2020 Core Update to learn more about that point (and other important points that site owners should know about Google’s broad core updates).  

During the audit, I surfaced a number of key problems and the site owner has been moving as quickly as possible to implement those changes. One of the issues I surfaced involved user frustration and not meeting expectations based on query.

The site had a number of pages that were ranking well for queries where users had a very specific intent (and I would go as far as saying it was an extremely strong intent). Unfortunately, the pages could not help users achieve that goal. They tangentially covered the topic, but couldn’t provide exactly what users were looking for.

And beyond that, the pages contained information and links that might lead some users to believe they could still find a solution deeper on the site. This could lead to the engagement trap situation I mentioned earlier where users end up digging and digging with no possible way to find gold.

To show the impact during a broad core update, here are two pages like this on the site and their respective drops during the January 2020 core update:

As I was auditing the site, I began to experience user frustration like I mentioned earlier… I was running in circles when I put myself in the shoes of a typical user. It was extremely frustrating… and although I could see many clicks leading to these pages, GSC alone couldn’t provide the full story. So I switched to Google Analytics and a feature that I believe is completely underutilized – Behavior Flow.

Behavior flow enables you to visualize the journey users take through your site based on a dimension you select as a starting point. For example, you can view the path through your site based on traffic source, medium, campaign, landing page, and more. I bolded landing page since that’s exactly what I’m going to show you below for the page type I covered earlier.

Here is what Behavior Flow reporting looks like in GA:

A quick note about sampling:
It’s important to know that Flow Visualization reports in Google Analytics are sampled. Behavior Flow is based on 100K sessions based on the selected timeframe. To get around sampling, you can always shorten the time range to get the number of sessions under the sampling threshold. Just keep this in mind while reviewing the reporting.

When “Engagement” Could Mean Frustration: How To Use Behavior Flow To Visualize Frustrated Users
During the engagement, I ran a traffic drop report (previously called Panda report) to surface the largest drops by landing page after the January and May core updates. Again, the site had a number of key problems across various page types that were problematic. One was the page type I explained earlier, which not only couldn’t meet or exceed user expectations, but it also had the potential to lead users to more pages thinking they could find a solution.

I checked Google Analytics for landing page metrics and noticed one of the problematic urls had a 65% standard bounce rate. That means 35% of users visited another page on the site (which accounts for nearly 20K users during the timeframe). I wanted to see where those users were visiting after the landing page. In other words, were they happy with their visit or were they banging their head against their monitor while endlessly roaming around the site in search for a solution?

So I jumped to Behavior Flow in Google Analytics and set my starting point as that landing page. And once I did, I immediately noticed a problem. And that’s pretty much what I thought I would see!

For this page, 65% dropped off after visiting the landing page during the timeframe I selected (pre-core update). That’s not surprising, but the 35% remaining on the site displayed a path of frustration that was hard to ignore.

The next step for almost all of the users, which is labeled the “first interaction” after the landing page, was to pages that seemed like they could provide a solution, but really couldn’t. So, the landing page couldn’t meet user expectations and then 35% of the users landing on that page ended up visiting another page that couldn’t meet expectations either. Not good, but we’re just getting started.

And then the second interaction was eye-opening. 68% of the users that clicked to a second page went back to the original page they visited from the search results! Yep, I was beginning to see user frustration in the visuals. They visited the landing page from the SERPs, couldn’t find what they were looking for, visited another page thinking they could find a solution, but couldn’t. So they went right back to the original landing page still looking for a solution!

But the fun doesn’t stop there. The third interaction reveals users visiting even more pages from that original landing page believing they could find a solution. 20% of the users visiting the original landing page were now three interactions into their visit, with no hope of finding a solution.

But we’re not done yet. I keep using the word “trap” in this post and the fourth interaction underscores why. To quickly recap, we have users landing on a page (mostly from the SERPs), visiting another page to find a solution, then jumping back to the original landing page, and then desperately visiting more pages to find a solution.

What do you think happened next??

Yep, they went back to the original landing page again! 14% of users were now four interactions into the site (but back at the original landing page). Ugh.

And if they haven’t had enough, some users were still jumping to other pages from the original landing page to find a solution. Oh, those poor people… :)

As you can imagine, this led to a horribly frustrating experience for those users. And over time, hundreds of thousands of users were going through this process. I’m not saying this is the sole reason the site got pummeled by two core updates (remember, there are “millions of baby algorithms” at play with core updates), but it sure doesn’t help matters.

Using behavior flow in Google Analytics enabled me to visualize the frustration that users were experiencing while entering specific landing pages (and most visitors were from Google organic). And that visualization can go a long way when explaining to site owners how certain things need to change on a site. I know this example did.

I’ll end this post with some final tips and recommendations based on going through the process of visualizing user frustration using Behavior Flow in Google Analytics. Again, the great thing is you can go through this process today, and it’s free.

Using Behavior Flow To Visualize Frustration: Tips and Recommendations

  • Identify high volume pages and dig into the data. Make sure you understand what’s going on user engagement-wise. Don’t assume all visits end with happy users.
  • You can also run a traffic drop report to identify the biggest drops to landing pages across the site based on a core update, and then dig into those pages.
  • Don’t just check a metric like standard bounce rate and make decisions. Dig deeper with other user engagement metrics and with additional functionality like Behavior Flow in Google Analytics.
  • Use specific landing pages as the starting point in Behavior Flow and visualize the journey through your site. This is how you can identify engagement traps like I covered in this post.
  • If you identify engagement traps, take action before Google takes action. Always try to meet or exceed user expectations based on query. Don’t wait until you drop based on a broad core update to fix user engagement problems, content quality, and more. Identify key problems with those pages and fix them as quickly as you can.
  • Track Behavior Flow over time for the pages you identify as engagement traps. You should see improvements in the data and through the visualizations in the reporting after you fix those problems.

Summary – “Hell hath no fury like a user scorned”
This case study demonstrated how you can back up SEO intuition by using Behavior Flow in Google Analytics. By using this underutilized feature in GA, you can view the journey users take through your site. And you can use a number of dimensions as the starting point, including landing page.

Behavior Flow can absolutely help you identify problematic situations and then effectively communicate that story to site owners (backed by data). And that can help drive change. Like I said earlier, the amazing part is that it’s freely available in Google Analytics. You can literally start checking this now. So fire up Google Analytics, find those engagement traps, and fix them soon. Take action before Google takes action.

GG

How To Remove An Image From Google Search Using The Outdated Content Tool (When The Image Was Published On Another Site)

By Leave a Comment

How to remove images from Google.

There are times that pesky image search results stick around on Google even when those images have been removed from the web (or at least you think they have been removed from the web). I’ve received many calls over the years about this very situation. And many times, the images that people want to remove are on third-party sites outside of that person’s control. For example, profile photos from Twitter, Facebook, images from articles that have been removed, etc.

Since the sites aren’t under your direct control, your options are limited. For example, for times you can’t directly access the third-party site and you can’t access the Google Search Console (GSC) property for the site to use the Removals tool. From an image search standpoint, it can unfortunately lag behind web search for updating and/or removing files. And that can result in images hanging around the search results when they really should be removed, which can be extremely frustrating.

So what can you do??

Well, as long as the image has been removed from the third-party page that contained it, or if the page has been entirely removed from that site, Google provides functionality for quickly removing that image from the search results. On that note, I find there’s a lot of confusion about the various tools Google provides for removals, and how to use them. I’ll explain more about that soon.

For this post, I’m going to show you how to remove an image from Google Images, when that image resides on a third-party site (out of your control). I’ll walk you through using the Outdated Content Tool to target those images and remove them from the image results.

The Removals Tools in GSC Versus The Outdated Content Tool
First, I know many people aren’t familiar with Google’s Outdated Content Tool, which has been around for a long time. It’s a publicly available tool that you can use to request removal of webpages or images (as long as that content has actually been removed). I have used this tool many times over the years when helping clients. And it’s important to understand that it’s different from the Removals tool in GSC.

It’s also important to note that the content you are attempting to remove from the search results must have been removed already from the third-party site for this tool to work. You cannot simply log into the tool and start nuking content from another site when that content still exists.

In the tool, you can request new removals (e.g. webpages or images) and you will also see previous requests and the status of those requests.

Again, this is different from the Removals Tool in GSC, where you can temporarily hide content from the search results from sites you control for six months (while you actually remove the content on your site). And if the content is removed behind the scenes, it will remain out of Google’s index, and out of its search results long-term (beyond the six-month temporary removal).

Adding More Confusion To The Removal Tools Situation
The new Removals Tool in GSC will also show you “outdated content removal requests” (which were submitted via the public Outdated Content Tool I mentioned earlier! So as a site owner, you can see any content that someone has attempted to remove on your site using the public tool.

Note, I would check this report soon… since you might be surprised what you find there. For example, I’ve seen people try to remove important files or directories from sites they don’t control using the tool. Scary, right? Of course, since the content was still present on the site, Google declined the removal request and nothing happened. But it’s still important to know what’s going on there.

For example, here is a screenshot showing three submitted requests flagging my client’s content as “explicit”. All three were denied by Google, but scary to think there was an attempt like that:

How To Remove An Image From Google Images Using The Outdated Content Tool
Now that I’ve covered the various removal tools from Google, I’m going to walk you through removing an image from Google Image Search. If you have an actual image you want removed, then now is a great time to use that image while following along.

Google provides a help document listing the necessary steps and I’ll walk you through those steps below (along with any tips I can provide along the way):

1. Go to Google Images and search for the image you want to remove.

2. From the search results, right-click on that image and select “Copy Link Address”. Don’t click the image… just right-click directly in the search results when you find the image.

3. I recommend creating a text file that contains the urls you want to remove. There may be more than one url when it’s all said and done and it’s best to store them in a file for future reference. Paste the url you just copied from the image search results into that text document.

4. There are times one image ends up being multiple images. That’s because some sites keep images in multiple sizes or at multiple urls. So, you want to make sure you copy all of those image urls for removal. If not, as one image is removed from the search results, another might take its place.

You can find other urls for the same image by right-clicking on the image in the search results and selecting “Search Google for Image”. If there are other sizes, click the links to view the image results for the other sizes. Then right-click and copy the urls like we did earlier (directly from the search results).

5. Go to the public Outdated Content Tool and paste the urls one by one into the tool and click “Request Removal”. You will need to enter each url separately. Note, I’m not actually submitting the form to remove the image from Google. It’s just an example for the tutorial. :)

Depending on the type of removal, you will see a different message. For example, if it’s just the image you are removing, and the page has been removed on the third-party site, then you will see a message explaining that the image is “no longer live on the website”. If it is gone, you can continue by clicking “Request removal”.

If you are removing an image that has been removed from a page, but the page still remains, you will see a different message. If the image has indeed been updated or removed from that page, then you should click “Yes” in the form and continue. And in case you’re wondering, the webpage isn’t going to be taken down… it’s just the image that will be purged. That’s what you want.

Congratulations, you have successfully requested removal of an image from Google Images! Well, sort of… Now you need to let Google do its thing and remove the images from Search. More about that next. You will see the status of “Pending” until the images are removed.

How Long Does It Take Before The Image Is Actually Removed? It’s Pretty Quick
When you request removal of an image, Google can work really fast. I’ve seen images removed within a day or so. You can always check the Outdated Content Tool to see the status of the removals. And you can obviously check Google Images to see if the images are indeed gone from the image search results. When the images are removed, you will see the status change from “Pending” to “Removed”.

And you will also see the type of removal requested. The status could be “Outdated page removal”, which is when the entire page has been removed, or “Changed content”, when the just an image has been removed from a page that still exists.

It’s important to note that when you are removing content from a page that still exists, Google will first purge the snippet and the cache for that page. Then the cache and snippet will be refreshed the next time the page is crawled. If you want, you can run a site query on the page and you will see the listing without a snippet and cache link.

For example, enter site:{enter page url here} in Google. You should see the snippet has been removed and the cache link is gone until Google recrawls the page.

Summary – Removing Images From Google That Are Caught In The Matrix
Having an image linger around Google Images when it has really been removed can be very frustrating. But as you can see, there are ways to remove those images from the search results (from third-party sites) by using the tools Google has provided. And once you submit your removals, it only takes a day or so for the images to be removed from the results. But remember, make sure the images have really been removed from the web. If not, the request will not be successful. 

GG

Chrome’s Timeline For Blocking Mixed Content – Examples of Blocking, How SEOs Can Test Pages, and How To Prepare For Mixed Images in Chrome 81

By Leave a Comment

In October of 2019, Google announced a plan to gradually block mixed content over time. Mixed content is a common issue across sites where secure pages attempt to load insecure content. For example, loading an image file over http from an https page. There are security risks associated with that, so Chrome wants to eliminate that risk in the future (by blocking mixed content from loading).

Since it’s a common issue, Chrome announced a staged plan in October so site owners would have plenty of time to research and fix mixed content issues on their sites. Even though the blog post was published in October of 2019, I’m still seeing a lot of confusion about the topic when working with clients. In addition, I’m finding many companies don’t even know that Chrome has begun blocking some types of insecure content already. 

In this post, I’ll first cover the timeline that Google mapped out for Chrome’s handling of mixed content. Then I’ll cover how the problem could break pages visually, I’ll cover the rendering impact, I’ll provide examples of what blocking looks like, and then I’ll end with some final tips.

Chrome’s Mixed Content Timeline:
In Google’s blog post about blocking mixed content over time, they provided a staged rollout. The plan was to gradually block mixed content versus simply flipping a switch and having pages break.

  • The first change was in Chrome 79, where Chrome started providing a setting where users could unblock mixed content on specific sites. The setting applies to mixed scripts, iframes, and other types of content that Chrome blocks by default.
  • In Chrome 80, which is the current version of Chrome as I write this article, Chrome will attempt to auto-upgrade audio and video resources to https (if possible). If the resources cannot be auto-upgraded, then Chrome will block the resources from loading. This is completed automatically by Chrome for sites trying to load audio or video resources over http from an https page.
  • In addition, Chrome 80 will allow mixed images to load, but that will cause a “Not secure” label to be displayed in the browser. So, loading images over http will still allow the images to appear on the page (as of now), but the url will have a “Not secure” label in the browser window.
  • Then in Chrome 81, which was supposed to be released in February 2020 but hasn’t rolled out, Chrome will attempt to auto-upgrade mixed images to https. If they fail to load over https, then Chrome will block those images completely (they won’t load on the page).
  • Regarding the rollout of Chrome 81, the Chrome team announced that based on the global pandemic, Chrome 81 will not be released yet. Therefore, the final stage in the gradual rollout of blocking mixed content is not live yet. But, you can test it out via the Canary build of Chrome (which I’ll cover soon). As of today (Chrome 80), the stable version of Chrome is not auto-upgrading or blocking mixed images yet. It’s just showing a “Not secure” label for mixed images. But Chrome 80 is auto-upgrading audio and video resources to https and blocking them if they won’t load over https.

Insecure Images, A Common Mixed Content Issue
I’m sure some site owners and SEOs reading this post are confused about what mixed content is and how it looks. First, if you are running your pages over https, then all resources should be loaded over https. If you try to load resources over http, then that’s where mixed content warnings arise. Again, it’s a common issue that’s impacting many sites across the web.

As a simple example, here is a secure page (https) that is loading three images over http (insecure) in the stable version of Chrome (v80). Notice the “Not secure” label in Chrome versus the secure padlock.

When using Chrome Dev Tools and checking the security tab, you can view the resources that were loaded over http. You typically need to refresh the page to see those resources.

Since we are in stage three of the rollout (Chrome 80), the images will be allowed to load, but Chrome will display a “Not-secure” label in the browser window. To clarify, the images will still show up on the page and you will not run into any rendering issues (yet).  

It’s worth noting that audio and video will be auto-upgraded to https in Chrome 80. If they can’t be loaded over https, then the content will be blocked entirely. I’m focusing on images in this post, but that’s important to know if you are using audio and video on your pages.

Chrome Canary – The Ability To See Into Chrome’s Future
The Chrome Canary build is a version of Chrome that’s updated nightly with the latest functionality. It’s a great way to test your site and functionality for future versions of Chrome. There are many times I’m activating functionality in Canary that’s not yet in the stable version of Chrome to see how that will work when it finally does roll out. 

Since I know that Chrome 81 is nearing release, I was able to test how Chrome would handle mixed images. Remember, the stable version of Chrome simply adds a “Not secure” label in the browser window, but Chrome 81 will auto-upgrade those mixed images if possible. And if the images cannot load over https, then they will be blocked entirely. That means they won’t load on the page. And that also means it can impact what Google sees when it renders your pages.

As a quick example, I set up a page that loads an image via http and that image cannot be auto-upgraded to https. As you can see below, the image is blocked entirely from Chrome (and doesn’t show up on the page). The page actually shows up as secure in Canary (the “Not secure” label has been removed), but the page simply displays a missing image icon. That’s not good if it’s a critical piece of content for users.

Image blocked from loading:

The page is now secure, but the image is blocked:

The resource failed to load since it can’t be auto-upgraded:

Evergreen Googlebot, Broken Renders, and Ranking Impact
OK, so now we know that mixed images will not load in Chrome 81 if those images cannot be auto-upgraded to https. And we saw how that looks in the browser with broken image icons showing up on the page. That’s not good for users at all, but what about Google?

Google’s John Mueller has explained that since Google uses an evergreen Googlebot now for rendering, it will be using the latest version of Chrome. That means it will be using Chrome 81 once that rolls out. Again, that hasn’t rolled out yet due to the global pandemic, but it will at some point soon.

So if Googlebot will be using Chrome 81 to render your content, and we already know that Chrome 81 will block mixed images, then that’s exactly how Google will see it. So key images will be missing from your renders if those images cannot be loaded over https.

In addition, from a ranking perspective, John explained that the blocking of images shouldn’t impact rankings based on Google’s https ranking signal. That’s good to know, but he also explained that if the pages cannot render completely in a browser, then Google probably won’t be able to render those parts either. And he clearly recommended fixing that issue.

Here is a link and screenshot to a reddit thread where John explained this:

Wrapping Up and Final Tips:
Before I end this post, I wanted to provide a number of final tips and suggestions based on researching this topic. Remember, site owners still have time before Chrome 81 rolls out to address mixed content issues. Based on what I provided in this post, it would be smart to rectify those issues now before Chrome 81 rolls out. Here are some final tips:

  • Crawl your site and surface all mixed content issues. My three favorite crawling tools are DeepCrawl, Screaming Frog, and Sitebulb. All three provide specific reporting for mixed content. Note, I’m on the customer advisory board for DeepCrawl. It has been one of my favorite enterprise crawling tools since 2013.
  • Understand that Chrome 81 has NOT rolled out yet and Google has paused updates due to the global pandemic. Chrome 80 is the stable version of Chrome now and it does display a “Not secure” label for pages with mixed content problems. Also, Chrome 81 will roll out relatively soon and will completely block mixed images that don’t load over https (when auto-upgraded).
  • Chrome 80 currently attempts to auto-upgrade audio and video to https. And it those resources fail to load over https, Chrome will block them from loading.
  • Mixed content problems can impact your pages visibly for users, and for Google rendering your pages. Remember, Google now uses an Evergreen Googlebot, which utilizes the latest version of Chrome to render your pages. That means Googlebot will be using Chrome 81 to render pages once it rolls out. As Google’s John Mueller explained, you definitely want to fix mixed content issues that impact rendering.
  • John Mueller also explained that this shouldn’t impact rankings based on Google’s https ranking signal. That’s good news, but again, it can impact what users see on your pages and what Google is able to render.
  • You can use Chrome Canary to test your pages now to see how mixed content will impact your site once Chrome 81 rolls out. It’s a great way to test Chrome’s latest and greatest functionality that hasn’t rolled out to the stable version of Chrome yet.

Address Mixed Content Issues and Avoid Broken Pages and Partial Renders
In this post, I covered Chrome’s plan to gradually block mixed content. The final stage of the rollout will be completed when Chrome 81 is released as the stable version of Chrome. But as I covered in my post, the release of Chrome 81 has been delayed due to the global pandemic. Therefore, you still have time to fix mixed image problems before Chrome blocks them from loading (if they can’t be auto-upgraded to https). And remember, audio and video resources are already being blocked if they can’t be auto-upgraded.

I recommend thoroughly testing your site to ensure you surface, and then fix, mixed content problems. Then you can rest assured that both users and Googlebot can load and render all of your resources, including images, video, and audio.

GG

Revisiting The SEO Importance of Quality Indexation For Large-Scale Sites: Hunting High Indexation and Low Search Value By Directory [Case Study]

By Leave a Comment

Quality Indexation for SEO

A Quick Reintroduction To Quality Indexation:
I’ve covered the importance of what I call “quality indexation” many times in my posts about major algorithm updates. It’s an extremely important topic, especially for larger-scale sites. When I refer to quality indexation, I’m referring to the importance of making sure your highest quality content gets indexed, while ensuring your low-quality or thin content remains out of the index. With Google confirming that it takes all pages indexed (10:06 in the video) into account when evaluating quality (25:20 in the video) for a site, it’s important to make sure your ratio is strong.

I see weak quality indexation rear its ugly head often while helping companies that have been negatively impacted by Google’s core algorithm updates. For example, there may be sections of a site containing massive amounts of indexed urls that are thin or low-quality. So the ratio of high quality content to low-quality content is not strong.

And when checking traffic to those areas from organic search, you don’t see much. So, you have massive indexation with low traffic levels from Google organic. That’s not a great combination for site owners and SEOs. I’ll provide more information about this soon.

In addition, this situation can cause crawl budget issues. Note, most sites (like 99.9%) don’t need to worry about crawl budget. But larger, more complex sites often do need to worry about it. For example, a large-scale site with millions of urls, and a complex setup, should definitely make sure crawl budget isn’t an issue. So, we have quality and crawl budget concerns when quality indexation is weak.

For example, here’s the coverage reporting for a large-scale site with millions of pages indexed and tens of millions of pages excluded. It’s extremely important for this site to focus on strong quality indexation:

Crawl budget can be an issue for large-scale websites.

In worst-case scenarios, there may be millions, or tens of millions, of low-quality urls indexed that can end up dampening the quality of the site overall in Google’s eyes. I am working with a client now where this is the case. The good news is that we are actively working on fixing the situation once I uncovered the problem. The bad news is that this has been in place for a long time and Google will need to figure the changes out over time across tens of millions of urls. That said, the site owner wants to get the site in order for long-term success and understands this is the right way to proceed.

In this post, I’ll explain a process for identifying weak quality indexation across a large-scale site by directory. It’s a strong approach, especially when you’re dealing with a large and complex site.

Pre-Audit Analysis In GA and GSC:
Before fully digging into an audit, it’s always a good idea to spot-check certain reports in GSC, review the search history of the site, and more. You can sometimes find glaring issues that give you a hint about what’s going on with a site and why it has lost rankings.

For large-scale sites, GSC’s coverage report is gold. It reports on errors, pages indexed, and then contains an entire section for urls excluded from indexing. I’ve mentioned the coverage report many times in my posts about SEO and I can’t emphasize enough how powerful the reporting can be.

And when you combine the coverage report with data from the performance report, you can often identify problematic areas of the site from a quality indexation standpoint. For example, are there areas of a site with millions of pages indexed, yet those pages receive very little traffic (or no traffic)? If so, why?

The Performance and Coverage reports in Google Search Console (GSC)

And when checking the performance report, you can cross-reference Google Analytics data to see overall traffic to a page (or section) and isolate Google organic traffic. That can also help you figure out the importance and value of certain page types.

And if it’s a large-scale site with millions of urls, are xml sitemaps in order? How does indexation look when reviewing the coverage reporting for those sitemaps specifically (which you can do in GSC).

Sitemap error in Google Search Console (GSC)

Google has explained that sitemaps are extremely important for larger-scale sites. For example, Google’s Gary Illyes said sitemaps are the second most-important source of URL discovery. In addition, John Mueller has explained that sitemaps can help Google understand canonical urls, when those urls change (by providing an accurate lastmod date per url), and more.

Google's Gary Illyes explaining that xml sitemaps are the second most important source of URL discovery.

And all of what I mentioned above can help you answer a number of important questions. For example, should the pages be indexed or are they bogging down quality for the site? Are people even searching for topics that those pages could address? And can those pages meet or exceed expectations?

This process can often yield many pages that can be improved, or nuked from the site by either noindexing or 404ing the urls in question (if they simply shouldn’t be indexed). You can also find urls that should be canonicalized to other urls if they contain duplicate content. All of this is important to know so you can take action.

The Importance And Power Of Adding GSC Properties *By Directory*:
OK, so you now you’re excited to jump into GSC’s coverage report to begin some detective work. Well, I have some bad news for you. First, the coverage report will cover the entire site, so you can’t slice and dice your data by directory. Second, the reporting is limited to just one thousand urls per report. That’s clearly not sufficient when dealing with a site that contains millions of urls.

Note, I’ve repeatedly asked Googlers for an index coverage API so you can export all urls by report. I even did this in person at Google’s webmaster conference where I spoke with the GSC product team directly! I’m sad to say that I don’t believe it’s coming any time soon, so let’s move on.

So what’s a site owner to do when there are limitations like that?

Well, there’s a hack that works pretty darn well. And it can help you isolate problems per directory and gain a better understanding for quality indexation levels across each directory. The solution is adding properties to GSC for each directory. I’ve written a few blog posts about this topic and I always tell clients with larger-scale sites to set this up ASAP.

After adding each important directory to GSC, you can view the coverage and performance reporting JUST FOR THAT DIRECTORY. You can get a better feel for that directory by drilling into the various reporting without having to worry about the other directories muddying up the data.

Google's documentation for adding directories as properties in Search Console (GSC)
Adding a directory to Google Search Console (GSC) as a property

Case Study: Drill Into Directories And Let The Data Guide You
Back to the case study. Earlier I explained that I’m helping a client with a pretty serious quality indexation problem and it’s a great example of what I’ve explained so far in this post. By using the methods I covered, it was easy to identify problematic areas of the site where many pages were indexed, yet those areas received almost no organic search traffic.

And I’m not talking about a few thousand pages indexed here or there. I’m referring to millions of pages indexed with almost no organic search value at all. That helped us identify clear candidates for deindexing (either via noindexing, 404ing, or by canonicalizing urls that were duplicates).

Below, I’ll cover some quick examples of high indexation and low search value. I think you’ll get the picture pretty quickly. Let’s begin.

Directory One – Weak Quality Indexation
The directory contains pages targeting broad queries that this site will never rank for. It’s not even the main focus of the site. There are 25.3K pages indexed according to GSC, yet only 28 clicks. Yep, just 28. GA shows very low levels of traffic from Google organic as well.

Quality indexation problem example one.
Quality indexation problem and low traffic from Google organic.

Directory Two – Weaker Quality Indexation
The next directory that raised red flags yielded even weaker quality indexation levels. It also covered an area of content that was fine to have for users once they are on the site (it was tangentially relevant to the main topic for the site), but the content wasn’t great and many people wouldn’t even be searching for this type of information. There are 125K pages indexed in the directory, yet only 39 clicks in GSC.

Quality indexation problem example two.
Low traffic levels from problematic areas of a site.

Directory  Three – Duplicate content not handled properly.
The third directory I checked contained mass-duplicate content that was not being handled properly. For example, the urls should be canonicalized to the true canonical urls. There were 491K pages indexed in this directory, yet there were only 224 clicks during the time period.

Quality indexation problem example three.
Low number of clicks from Google organic to problematic areas of a website.

Directory Four – This is getting scary.
The next directory that I had concerns with had a whopping 3.04M pages indexed. It yielded more traffic than the previous three I checked, but still only 5.79K clicks. That’s not very much based on total indexation for the directory. Not good.

Quality indexation problem example four.
A low ratio of traffic to indexed pages for a problematic area of a website.

And with each additional directory I checked, I saw more of the same. Many pages indexed that weren’t yielding any (or much) organic search traffic. This was a great example of how weak quality indexation could bog down a site.

Moving Forward: Taking Action To Improve Quality Indexation
I’m working with the site owner to fix this situation as quickly as we can. Since it’s a huge site, this will take time to fix and then time for Google to reprocess the changes. Our goal is to make sure only the highest-quality pages are indexed while ensuring low-quality, thin, or duplicate content is handled properly from an SEO standpoint.

Below, I’ll end this post with some final tips and recommendations for enhancing quality indexation. Again, it’s an incredibly important topic for SEO.

Some tips and recommendations when investigating quality indexation problems:

  • First, if you manage a large-scale site, make sure you focus on thoroughly understanding quality indexation levels across the site (by directory if you can). Don’t end up with many low-quality or thin pages indexed.
  • As I covered earlier, definitely add GSC properties by directory if you can. That will enable you to isolate those directories and view all GSC reporting by that subfolder.
  • Understand the organic search value for each directory. You can leverage both GSC and GA data to verify traffic per site section and compare that to indexation per directory. And you should crawl those areas to fully understand what’s going on there from a content standpoint, technical SEO standpoint, etc.
  • Objectively analyze pages from each directory to understand the true value for the user. Ask yourself what would users search for to find that content? And if they find the content via Search, would it meet or exceed user expectations? If you’re having a hard time answering those questions, the pages could be good candidates for deindexing.
  • Form a plan of attack for improving quality indexation across the site. And understand volatility will probably come along for the ride if you are implementing significant changes across a large-scale site. That said, do what’s best for the long-term health of the site.
  • Track changes the best you can by documenting your coverage reporting and search analytics reporting over time. Coverage reporting is just for the past 90 days while search analytics data is for the past 16 months.
  • Don’t forget to set up accurate and thorough xml sitemaps (especially for larger-scale sites). They can help on multiple levels as I mentioned earlier. And if you are running a large-scale site, use sitemap index files to make sure you have full coverage of your site’s canonical urls. Make sure lastmod dates are accurate and are updated whenever content significantly changes across pages.

Summary – Don’t let weak quality indexation drag down your site.
In this post, I documented a good case of a site dealing with quality indexation problems. And with Google confirming that every page indexed is taken into account when evaluating quality, having millions of additional low-quality or thin pages indexed is not a good thing.

If you manage a large-scale site, this can become especially dangerous SEO-wise. I recommend going through the process I documented above and surfacing quality indexation problems. Then you should address those problems efficiently to enhance the long-term health of the site. You might experience some volatility in the short-term, but your goal should be long-term SEO success. I would focus on that. Good luck.

GG