Don’t skip these critical recurring SEO tasks

As we near the end of the year, it’s time to review bro­ken links, plu­g­ins, func­tion­al­i­ty and page speed before there is a cri­sis.

No mat­ter how per­fect­ly you’ve opti­mized a web­site, it will always require con­stant main­te­nance. This is because fig­u­ra­tive­ly speak­ing, much like a vehi­cle, there are a lot of mov­ing parts and many of those parts have an impact on oth­ers.

There are some tasks, like migrat­ing from HTTP to HTTPS, that are done once. Oth­er tasks are per­formed on a week­ly or month­ly like con­tent devel­op­ment, and oth­ers that might be con­duct­ed on a quar­ter­ly or year­ly basis.

As we near the end of the year, many mar­keters will begin plan­ning for next year. It’s equal­ly impor­tant to review what we’ve done through­out the year to make sure that our work didn’t inad­ver­tent­ly cause issues in oth­er areas. This helps us to get the most from our efforts as well as to begin next year with a head start.

In this arti­cle, I’m going to dig into the tasks that we typ­i­cal­ly han­dle on a quar­ter­ly or year­ly basis, because frankly, they often get ignored until there is a cri­sis. Proac­tive­ly han­dling them will give you a pow­er­ful advan­tage over com­peti­tors.

Crawl for broken links

Pages get moved or delet­ed. Images get replaced. Exter­nal resources move or even dis­ap­pear.

Over time, these seem­ing­ly minor changes can have a sig­nif­i­cant impact on a web­site. Often the impact is pos­i­tive. But when it results in bro­ken links that aren’t resolved, the neg­a­tive impact can add up quick­ly.

It’s easy to fix some bro­ken links on the spot by updat­ing the main nav­i­ga­tion when core pages are moved or delet­ed. It can be more com­pli­cat­ed when inter­nal links with­in con­tent come into play.

This is where spe­cial­ized tools are espe­cial­ly use­ful.

Rather than man­u­al­ly review­ing each page, which is what we had to do when I first got into SEO, you can sim­ply use auto­mat­ed soft­ware to do the heavy lift­ing. An added ben­e­fit is that unlike humans with short atten­tion spans, the soft­ware will catch every bro­ken link.

Review content for quality and relevance

If you’re doing that, you’ll typ­i­cal­ly find that over time, some of that con­tent will become irrel­e­vant or may no longer meet your qual­i­ty stan­dards. Some of this con­tent may need to be pruned or improved.

This isn’t a bad thing. It’s just the nature of con­tent devel­op­ment.

As we approach the end of the year, now is the effect time for this. Most busi­ness own­ers are elbow deep in eval­u­at­ing their per­for­mance for the year and plan­ning for the next year.

I recent­ly reviewed one of our client’s web­sites for this rea­son and found a tremen­dous amount of con­tent, that while use­ful at one point, no longer served a pur­pose.

This hap­pens for a vari­ety of rea­sons.

For this par­tic­u­lar client, in some cas­es, it was news relat­ed to their indus­try that was no longer rel­e­vant. In oth­ers, it was con­tent about spe­cif­ic inter­nal events. And in some, for­tu­nate­ly, rare cas­es, it was con­tent cre­at­ed by the client’s staff that nev­er should have been cre­at­ed in the first case.

Once you’ve iden­ti­fied the con­tent on your web­site that doesn’t meet your qual­i­ty and/or rel­e­vance stan­dards, you’ll need to deter­mine what to do with it.

Some con­tent may no longer be rel­e­vant because of changes in your indus­try or your busi­ness. This con­tent can be delet­ed, and the URLs should then be redi­rect­ed to the most rel­e­vant con­tent that still exists. If there is noth­ing rel­e­vant to a par­tic­u­lar page that’s being delet­ed, then you can delete it with­out set­ting up a redi­rect. How­ev­er, if that page has any inbound links or has received any organ­ic traf­fic in the past twelve months, I high­ly encour­age you to find some­thing on your web­site to redi­rect it to.

This may mean rewrit­ing the con­tent, adding addi­tion­al infor­ma­tion, and even includ­ing images, data, and links to oth­er exter­nal resources. Just remem­ber — longer isn’t always bet­ter. You should aim to answer your vis­i­tors’ query clear­ly and con­cise­ly. Skip the fluff. If you can say every­thing that needs to be said with just 750 words, then there won’t be any­thing gained by inflat­ing it to 3,000 words.

Test for page speed

We already know, thanks to data from a vari­ety of sources, that page speed has a dra­mat­ic impact on user expe­ri­ence. We also know that it is a rank­ing fac­tor, both because we’ve seen the evi­dence and because Google has told us.

Just as low-qual­i­ty con­tent can grow over time, small tweaks to your web­site can add up to adverse­ly affect page speed over time as well.

A font file here, a JavaScript library there, and before you know it, your web­site is crawl­ing along slow­er than that dump truck you got stuck behind at rush hour. And don’t even get me start­ed on Word­Press plu­g­ins.

I can tell you from first-hand expe­ri­ence that this hap­pens to most web­sites that are main­tained and updat­ed reg­u­lar­ly. That’s why it’s so impor­tant to reg­u­lar­ly test page speed espe­cial­ly on your high­est traf­fic pages.

If you have a small web­site (under 1,000 pages), then I rec­om­mend test­ing all of your pages. The task isn’t as mon­u­men­tal as it may seem. We’ll talk about the exe­cu­tion short­ly.

For web­sites over 1,000 pages, my rec­om­men­da­tion is to first test the pages that dri­ve 30 per­cent of your traf­fic. Next, test any pages not includ­ed in that dataset that are crit­i­cal to your busi­ness. And final­ly, iden­ti­fy the pages in the bot­tom 10 per­cent in terms of organ­ic traf­fic, high­light any that are some­what to mod­er­ate­ly impor­tant, and test them.

The good news is that you don’t need to man­u­al­ly test each page. You can col­lect the ini­tial data right inside of Google ana­lyt­ics.

If a page typ­i­cal­ly loads in under three sec­onds, you’re good to go. If it typ­i­cal­ly takes longer than three sec­onds, it’s time to use a tool like WebPageTest.org or GTmet­rics to iden­ti­fy the ele­ments that are caus­ing the issues.

If fix­ing these type of issues is some­thing you’re not famil­iar with, you can check out a recent arti­cle I pub­lished on the top­ic, titled How to rev up your page speed for bet­ter web­site per­for­mance.

Review WordPress plugins

I men­tioned ear­li­er that Word­Press plu­g­ins could have a neg­a­tive impact on page speed. This is because they often include CSS and JavaScript files and some­times will even include JavaScript libraries that have already been enqueued by Word­Press core, the theme or oth­er plu­g­ins. Some will also include fonts like FontAwe­some or Ion­ic Icons, which more often than not, are loaded remote­ly. This has a tremen­dous and adverse impact on page speed. But the prob­lems don’t end there.

Plu­g­ins must be updat­ed by the author reg­u­lar­ly to con­tin­ue func­tion­ing prop­er­ly. This is due to changes in:

Word­Press

PHP and JavaScript

HTML stan­dards

Browsers

But for a vari­ety of rea­sons, plu­g­in authors may infre­quent­ly update their plu­g­ins to keep up with changes in this envi­ron­ment, or in some cas­es, may sim­ply aban­don them entire­ly.

This can affect func­tion­al­i­ty, appear­ance, page speed, and even tech­ni­cal SEO. In some cas­es, it can even ren­der an entire web­site inac­ces­si­ble.

It’s wise to review Word­Press plu­g­ins regularly—not just in terms of you hav­ing the most cur­rent ver­sion installed, but also in terms of whether the author has kept the plu­g­in up to date with cur­rent stan­dards.

While doing this, I also rec­om­mend putting seri­ous thought into whether each plu­g­in is real­ly nec­es­sary. If you can elim­i­nate a plu­g­in, not only will you typ­i­cal­ly improve page speed, but you’ll also reduce your main­te­nance work­load and poten­tial­ly improve secu­ri­ty. It’s a win all the way around.

Test layout and functionality in major browsers

I explained how incre­men­tal changes to your web­site could impact page speed, but they can also impact how some pages look and func­tion.

I had this hap­pen to me recent­ly with a client’s web­site.

We made a change to the CSS file to change the appear­ance of a par­tic­u­lar sec­tion but didn’t real­ize until it has been live for a few days that it also changed the appear­ance in anoth­er sec­tion. It was pure coin­ci­dence that we stum­bled across the oth­er sec­tion and spot­ted the issue.

Imag­ine how small changes through­out weeks or months could inad­ver­tent­ly add up to dras­ti­cal­ly affect the lay­out and func­tion­al­i­ty of unin­tend­ed ele­ments.

I rec­om­mend tak­ing an approach sim­i­lar to the one I explained for test­ing page speed. First, iden­ti­fy the pages that dri­ve 30 per­cent of your organ­ic traf­fic for test­ing. Then iden­ti­fy any pages not part of this group that is crit­i­cal to your busi­ness. You can skip the pages that deliv­er the bot­tom 10 per­cent of your organ­ic traf­fic.

Unfor­tu­nate­ly, to test lay­out and func­tion­al­i­ty, you will need to man­u­al­ly check these pages, but in most cas­es, it shouldn’t take more than a few sec­onds per page.