Website

[vc_row][vc_column][vc_column_text]In a webmaster hangout, a publisher asked how fast Google removed pages from the index if they added a noindex nofollow to it. The publisher stated they had added noindex but the page remained in Google’s index. Google’s John Mueller responded with an answer that described how often some pages are indexed.

John Mueller revealed that URLs are crawled at different rates. That’s somewhat well understood. What was of more interest was that he said some URLs can be crawled as little as once every six months.

The publisher stated:

“We’re seeing stuff that’s from a long time ago, where we’ve changed the noindex nofollow but we’re still seeing it in the index. And this is several months after we’ve changed this.”

John Mueller answered:

“I think the hard part here is that we don’t crawl URLs with the same frequency all the time. So some URLs we will crawl daily. Some URLs maybe weekly. Other URLs every couple of months, maybe even every once half year or so.

So this is something that we try to find the right balance for, so that we don’t overload your server.

And if you made significant changes on your website across the board then probably a lot of those changes are picked up fairly quickly but there will be some leftover ones.

So in particular if you do things like site queries then there’s a chance that you’ll see those URLs that get crawled like once every half year. They’ll still be there after a couple of months.

And that’s kind of… the normal time for us to kind of reprocess/re-crawl things. So it’s not necessarily a sign that something is technically completely broken.

But it does mean that if you think that these URLs should really not be indexed at all, then maybe you can kind of back that up and say well here’s a sitemap file with the last modification date so that Google goes off and tries to double-check these a little bit faster than otherwise.”

Use The Site Map to Trigger Updated Crawling

John Mueller suggested updating the site map and letting Googlebot discover the last modified date and using that as a hint for it to go out and crawl the old web pages.

Google URL Inspection Tool

Something John Mueller didn’t mention is using Google’s URL Inspection tool. According to Google’s Webmaster Help page on re-indexing,  a submission can take up to a week or two.

The URL Inspection tool is useful if you have a few individual URLs that need re-crawling. If you have a large amount of web pages, Google recommends submitting a site map instead.

More information on how to ask Google to re-crawl URLs here
https://support.google.com/webmasters/answer/6065812

Watch the Webmaster Hangout here
https://youtu.be/gC7aVygbMIk?t=2594[/vc_column_text][/vc_column][/vc_row][vc_section][vc_row][vc_column][vc_message message_box_color=”orange” icon_fontawesome=”fa fa-external-link”]This article was originally posted at Search Engine Journal by Roger Montti on October 16, 2018.[/vc_message][/vc_column][/vc_row][/vc_section]

[vc_row][vc_column][vc_column_text]

Contributor Janet Driscoll Miller points out three page load speed issues and provides simple but effective workarounds that will enable web pages to load faster and gain favor with Google.

There are multiple reasons to improve how quickly your web pages load. One of them is page abandonment.

If your pages load slowly and customers leave before seeing your services, how will you grow a business and be successful?

A recent Google study shows that 53 percent of mobile site visitors will abandon a website if it takes more than three seconds to load.

Of added importance to search engine optimization specialists (SEOs) is that page load speed is currently a ranking factor on desktop search and mobile page load speed will also become a ranking factor in July 2018.

I’ve seen a few common mistakes that can drastically impede a page’s load speed. Thankfully, many of these mistakes can be fixed quickly and easily, which is a good thing, since every little bit helps when it comes to improving page load speed!

Let’s look at three common issues that affect page load speed and how to correct them.

Image file size

Image file size may be the most common mistake I find when it comes to slow-loading pages.

Often, webmasters uploading content to our websites may not be well-versed in image optimizationor really understand why it’s important. The result can be very large image files used where a reduced size image could have been used just as easily and with the same visual result.

Here’s an example.

This image is from a blog. The top image represents the size of the image as it was displayed in the blog post.

The bottom image is the actual size of the source image used. Notice how much larger the source image is than the displayed version on top. The larger the image, the more pixels it must load. To save load time, try to size your image to the display size before uploading instead of just resizing the image using hypertext markup language (HTML) parameters.

If you use a content management system (CMS), there are also many plugins you can use to help resize images as you upload them to the page. If you search on “WordPress plugins to resize images,” you’ll find many to choose from, like Compressor, which is free. It will compress your image further without losing any quality.

Look for a resizing tool that will show you a preview of what the compressed image will look like before you take the leap and compress the image. That can be particularly helpful when working with a web designer who may have concerns about sacrificing image quality for compression.

Unused JavaScript

It is common for websites to use a header file and a footer file to set up the heading/navigation area and footer area of the pages respectively. Since these areas usually stay fairly constant on a website, including these files means you can program it once and use it on every page.

It’s really efficient, especially when making updates. For example, if you have a change to your navigation, make the change once in your header file, and it’s automatically updated on every page that includes that header file.

A problem arises with some JavaScript. There are definitely JavaScript elements you need on every page of your website – like Google Analytics tracking JavaScript. But other JavaScript elements may only be needed on certain pages of the website.

For example, we work with a hospital that has an events page on their website for Lamaze classes for expectant moms.

On the Lamaze class page, they have a feature to save the class event to your Outlook calendar, enabled by a JavaScript element contained in the header file. This is a great feature and helpful for the events section of the website, but the rest of the website doesn’t need or use this JavaScript element.

The JavaScript from the Lamaze page loads on every page of the website, whether it is needed or not on the page. Pages not utilizing that JavaScript have to load that script, increasing page load time because of an element that isn’t even needed on the page.

Evaluate the JavaScript you use in your header file. Is it necessary for it to be there? If not, can it be moved to the body area so that the script loads on just that one page and not every page? Hopefully, the answer is yes.

Loading items from third-party websites

If you need to load items such as social sharing buttons, video player embeds, trackers and advertisements from third-party websites, try to minimize when possible.

Why?

You do not control how fast a third-party server and assets on that server will load. If you happen to load assets from a third party that are slow-loading because of server issues, it could potentially affect your page load time. Here’s what Google has to say:

Third-party scripts provide a wide range of useful functionality, making the web more dynamic, interactive, and interconnected. These scripts may be crucial to your website’s functionality or revenue stream. But third-party scripts also come with many risks that should be taken into consideration to minimize their impact while still providing value.

Why do you need to be careful about third-party scripts?

• They can be a performance concern
• They can be a privacy concern
• They might be a security concern
• They can be unpredictable and change without you knowing.
• They can have unintended consequences

Use third-party assets if you need to, but be sure to do this only when necessary.

To close

If you can tackle these three common issues, you’re likely going to have a faster page load speed and help your SEO efforts. Sometimes a small amount of effort can yield a big difference![/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_message message_box_color=”orange” icon_fontawesome=”fa fa-external-link”]This article was originally posted at Search Engine Land by Janet Driscoll Miller on May 10, 2018.[/vc_message][/vc_column][/vc_row]

[vc_section][vc_row][vc_column][vc_column_text]As mobile-first indexing nears, the need to optimize for mobile has never felt so pressing. Even in its current iteration, mobile search is incredibly important for advertisers and businesses of all sizes. Consider these statistics:

• A majority of Google searches occur on a smartphone or tablet.
• 50 percent of local mobile searches are for local business contact information, says Hubspot:

• According to BrightEdge, 69 percent of mobile searchers stated they were more likely to buy from a brand with a mobile site that addressed their concerns.

Now, with mobile web design, speed takes precedence over almost any other ranking factor. Unfortunately, I’m not sure if half of the web is seriously optimized for mobile search.

According to Think with Google, 70 percent of mobile web pages take 7 seconds to load visual content above and below the fold.

Common mobile site errors include:

• Blocked JavaScript and cascading style sheets (CSS) files.
• Failed redirects.
• Poor graphical interfaces (e.g., tiny text and poor image pixelation).
• Clunky search functions.
• Obtrusive interstitials.

Fixing many of these issues requires investing in a responsive content management system (CMS) and the right configuration for your mobile site.

Yet many questions remain as to what configuration truly works best for your website. Responsive web design has dominated the industry as the preferred configuration, but as the mobile web becomes more competitive, should the industry move on?

Is responsive web design enough?

Now, creating a standalone mobile website is good from the end-user perspective, but it severely diminishes your website’s equity from a search engine optimization (SEO) perspective.

Beyond this, mobile domains can be a costly investment and even more costly to maintain.

My digital marketing firm uses responsive web design (RWD), as well as accelerated mobile pages (AMP) to create a truly mobile-friendly website for our clients. But we must remember that responsive web design was not designed for speed, it was designed for designers.

Chances are your CMS has a responsive web design plug-in.

RWD web pages take advantage of fluid grids to render images and on-page elements in proportion to their device. For technical teams, this presents clear advantages to mobile design, including:

• Responsive handling of on-page layout for different devices.
• Retaining all content on a single uniform resource locator (URL), as opposed to an m. domain.
• More cost-effective than creating a standalone mobile site.
• Sites can be accessed offline using hypertext markup language 5 (HTML5).

While RWD does have its advantages, it was mostly created as a low-cost way to optimize websites for mobile search devices. It was also a way to complete this with little effort as possible.

Problems with RWD websites still persist:

• Slow loading speeds: above 10 seconds without proper onsite optimization
• Designers still need to optimize for touch, as opposed to scroll-and-click interfaces
• Data visualizations need to be optimized for small screens (i.e., charts and graphs)

So, why is this important? While RWD is an effective solution for small businesses and publishers on a budget, many established businesses are already making the switch to higher-speed configurations, such as accelerated mobile pages and progressive web applications (PWA).

Is AMP the answer or a red herring?

AMP represents Google’s big push to speed up the internet, but is it only on its terms?

As a quick primer, AMP is essentially an HTML framework that works the same as a content delivery network, serving stripped-down versions of web pages to increase page speeds. AMP is ideal for publishers who serve news articles and blog posts. It’s very similar to Facebook’s Instant Articlesformat.

AMP is currently being employed by multiple search engines, and even AdWords ads. Using the “Fast Fetch” tag, AMP continues to become faster and easier to implement.

According to Google, over 900,000 domains have already adopted AMP, and that number continues to grow.

In fact, numerous publishers have reported astounding success after switching to AMP:

Google has also made it no secret that it prioritizes AMP web pages for its mobile news carousels.

Mobile web speed obviously has a huge impact on the user experience and your conversion rate.

Using Google’s cache, web pages with AMP load 2x faster at one-tenth the latency of traditional web pages. But herein lies the issue with AMP.

While we’d consider faster loading speeds as contributing to more valued user experience, it’s the sacrifice that AMP needs to undergo that has severely limited its digital marketing value and adoption.

Since AMP is loaded using Google’s cache and served as a different version of the original document, clicks are hard to track since they technically don’t occur on the publisher’s website. This has a significant effect on engagement. By serving a watered-down version of a web page, AMP is great for serving informative blog posts, but there’s an obvious disconnect between the initial click and further engagement with the site.

This means that publishers and e-commerce stores must theoretically offer two different versions of their offerings. AMP is essentially search-result ad copy.

As a side note, another thing affecting AMP’s adoption is Google’s failure to communicate with its customers.

Ask the average web user what an AMP article is or if they could recognize one, and you’ll probably receive a blank stare. Ironically, Google is doing a disservice to its own user experience by not properly communicating the importance and advantages of AMP to individual users. Instead, it’s relied on publishers to make the switch of their own volition.

Does this mean that AMP is a red herring that should be ignored? Not exactly, and it all depends on your website. Unfortunately, there’s another configuration that threatens RWDs hegemony and AMP’s burgeoning adoption.

What about progressive web apps?

You may be familiar with PWAs, although very few sites actually leverage this genius technology.

PWAs are websites that act like an app in every way but don’t require a download.

PWAs are accessed through the web browser and utilize Javascript or CSS, along with HTML, to create nearly instantaneous load speeds. Leveraging their universal resource identifiers (URI), PWAs are linkable when bookmarked or shared by a web user.

The main advantages of PWAs include:

• Ability to work offline.
• Universal access on all devices and web browsers.
• Comparable load speeds with AMP.
•  Faster transitions between web pages and navigation than traditional mobile domains.
•  Native app-like interfaces.
•  Indexable and linkable.
• Ability to send push notifications.

Primarily, PWAs are used by e-commerce stores to create faster checkout times and a better end-user experience. PWAs can increase engagement on your site and increase conversions through their ability to leverage offline resources and push notifications to continually communicate with users.

But there are also drawbacks to PWAs. It’s a rather costly investment and incredibly difficult to implement, meaning you’ll probably have to hire a professional web designer to do so.

A larger concern would be: why not just invest in an app? Users visit hundreds of websites weekly and have numerous apps stored on their phone. Their primary demand, above all else, is fast loading speeds, which AMP provides.

With this in mind, which mobile configuration is best for your website, as we embark on the mobile-first era?

Which mobile configuration is best?

AMP is ideal for publishers who only seek to drive more traffic to their blog or publication. Many website owners have struggled to implement AMP because many CMS’s still don’t have a plug-in available. Even still, with Google’s new mobile “AMP Stories,” WordPress and many notable CMS’s struggled to properly implement AMP.

On the other hand, PWAs work across all browsers, and progressive enhancements have made them secure from viruses and unwanted content.

In terms of speed, PWAs and AMPs both have nearly instantaneous load times. The biggest difference here is the speed of navigation that comes from PWAs, as all web pages will be hosted in this format, unlike AMP.

From a ranking perspective, AMP may be a ranking signal (no one knows yet), but if PWAs host nearly identical loading speeds, I don’t see AMP as possessing a clear advantage over PWAs.

From a web design perspective, AMP is a nightmare, as it strips away many of the graphical and user interface elements of the native design. On other hand, PWAs are able to render and serve all of your design elements in an app-like display, which makes them more user-friendly.

After switching a hypertext transfer protocol secure (HTTPS) PWA, AliExpress improved its conversion rate by 104 percent across all browsers.

Finally, PWAs are responsive to different browsers and can react to user permissions to create a smooth checkout experience.

In the end, the best solution is to combine both for a truly fast, homogenous experience. Major brands, such as The Washington Post, have already done this. With the greater search visibility and speed of AMP articles and the app-like interface of PWAs, combining both could significantly increase your user signals and offer a better experience for users.

Conclusion

The need to go mobile cannot be overstated, although we’re already past beating the dead horse. Responsive web design is a great first step, but I don’t believe it goes far enough for businesses competing in a competitive niche. This is especially true for publishers.

For e-commerce platforms, combining AMP with a PWA design truly offers the best mobile configuration available today. All I can say is, make the switch to a mobile-friendly website before it’s too late.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_message message_box_color=”orange” icon_fontawesome=”fa fa-external-link”]This article was originally posted at Search Engine Land by Kristopher Jones on April 30, 2018.[/vc_message][/vc_column][/vc_row][/vc_section]