Website redesign mistakes that destroy SEO

seo.jpg

Redesigning a website, whether it’s your own or a client’s, is an essential part of marketing today. It’s essential because technology, trends, and the expectations of users change over time, and if we want to remain competitive, we must keep pace with these changes. But this task, while essential, also presents certain risks from an SEO perspective. A number of things can go wrong during the process. These issues can potentially cause search engines to no longer view that website as the authoritative answer to relevant queries. In some cases, certain mistakes can even result in penalties. No one wants that. So in this article, we’re going to explore some of the common web design mistakes that can destroy SEO. Knowing the potential risks may help you avoid making the kind of mistakes that tank your organic search traffic.

Leavingthe development environment crawlable / indexable

Peoplehandle development environments in a lot of different ways. Most simply set upa subfolder under their domain. Some may create a domain strictly fordevelopment. Then there are those who take the kind of precautions to hidetheir development environment that would give a CIA agent a warm fuzzy feelingin that empty spot where their heart should be.

Itend to fall into the latter category.

Searchengines are generally going to follow links and index the content they findalong the way — sometimes even when you explicitly tell them not to. Thatcreates problems because they could index two versions of the same website,potentially causing issues with both content and links.

Becauseof that, I place as many roadblocks as possible in the way of search enginestrying to access my development environment.

Here’swhat I do. The first step is to use a clean URL that has never been used for alive website before. This ensures there are no links pointing to it. Next,disallow all bots using robots.txt, and set up an empty index page so thatother folders are not visible. In the past, I’ve even gone as far as setting uppassword protection, but in most cases, that may be overkill. You can make thatcall.

Fromthere, I’ll set up a separate folder for each website in development.Typically, the folder name will be a combination of incomplete words so thatit’s unlikely to be found randomly. WordPress will then be installed in thesefolders, and configured to also block bots at this level.

Arbitrarilychanging image names on pages that rank well

Thisisn’t always an issue, but if a web page is ranking well, changing the name ofan image on that page may cause a loss of ranking. Especially if the webdesigner doesn’t know what they’re doing.

I’veseen this happen more than a few times, where a client hires a web designer whodoesn’t understand SEO to redesign a website that alreadyranks well. As part of the redesign process, they replace old images with new,larger images, but, lacking the appropriate experience, they use stupid imagenames that provide zero SEO value, like image1.jpg.

Thistakes away a vital piece of context that search engines use to determine wherea particular web page should rank.

Deletingpages or changing page URLs without redirecting them

Duringa redesign, some pages will almost certainly no longer be needed. Lessexperienced web designers will often simply delete them. Other pages may bemoved and/or renamed, which in most cases, changes their URL. In these cases,inexperienced web designers often change these URLs and consider the taskcomplete.

Thisis a big mistake because some of those pages may already rank well. They mighthave inbound links pointing to them or have been bookmarked by visitors.

Whenyou delete pages that already have inbound links, you’ll lose all of the SEOvalue from those links. In some cases, this could result in a drastic loss ofranking.

Theissue goes even deeper though. Anyone clicking those links or bookmarks will begreeted by a 404 page. That presents zero value to anyone, and moreimportantly, it creates a negative user experience. This is important becauseGoogle has confirmed that user experience is a ranking factor.

Theproper way to delete pages is to redirect any them to the most relevant pagethat currently exists. As for moving pages, which includes anything thatchanges the URL of that page in any way, it’s equally important to redirect theold URL to the new one.

Inboth scenarios, a 301 redirect should generally be used. This tells searchengines that the old page has been permanently moved to the new location. Formost hosting platforms, this is best accomplished by adding the appropriateentry into your .htaccess file.

Ifyou’re unable to see a .htaccess file on your server, you may need to adjustthe settings on your FTP program to view hidden files.

Somespecialized hosting platforms may utilize a different method, so you mayneed to check with their support team to determine how to accomplish it.

Notperforming a full crawl after migration to and from the development environment

Regardlessof the method you use for migration you’re bound to run into some errors. Typically you’ll first migrate the live website into your developmentenvironment, and then later, send it back to the live server after you’ve madeand tested changes.

Onethat I run into frequently is links within content pointing to the wrong place.For example, within a page or post on the live website, you may have a linkthat points to:

Allis fine and good so far, right?

Butsometimes, while migrating the completed website back over to the live server,the content in pages and posts may still contain links pointing to the pageswithin the development environment.

Thisis just one example. There are countless links to content within a website —including links to the essential image, JavaScript, and CSS files.

Fortunately,the solution is simple. A tool like Screaming Frog, which runs from yourdesktop, or a cloud-based tool like SEMrush, can be used to crawl every singlelink within your website. This includes the text links visible on the frontend, as well as all of the links to image, JavaScript, and CSS files that aretucked away in the HTML of a website.

Besure to review all links to external sources once the new website has beenmigrated to the live server because any links pointing to your developmentenvironment will appear as external links — when you find “external links” thatshould really be internal links, you can make the appropriate corrections.

Thisstep is essential after migrating in either direction, in order to preventpotentially catastrophic errors.

Failingto perform a complete function check on everything

Oncea redesigned website has been migrated to the live server, you need to do morethan quickly review a few pages to make sure things look OK. Instead, it’s essentialto physically test everything to make sure it not only looks right, butalso functions properly.

Thisincludes:

  • Contact forms.
  • E-commerce functionality.
  • Search capabilities.
  • Interactive tools.
  • Multimedia players.
  • Analytics.
  • Google Search Console / Bing Webmaster Tools verification.
  • Tracking pixels.
  • Dynamic ads.

Failingto reconfigure WordPress and plugins after migration to the live server

Rememberhow we talked about the importance of putting up a wall between yourdevelopment environment and the search engines’ crawlers? Well, it’s even moreimportant to tear that wall down after migrating the website to the liveserver.

Failingto do this is easy. It’s also devastating. In fact, it’s a mistake I madeseveral years ago.

Aftermigrating a client’s website to their live server, I forgot to uncheck the boxin Yoast SEO that told search engines not to crawl or index it. Unfortunately,no one noticed for a few days, at which point, the website had been almostcompletely dropped from Google’s index. Fortunately, they didn’t rely onorganic traffic, and, once I unchecked that box, the website was quicklyreindexed.

Because of the impact mistakes like these can have,it’s critical that after migration to the live server, you immediately checkthe configuration of WordPress as well as any plugins that could affect howsearch engines treat your website.

This includes plugins for:

  • SEO.
  • Redirection.
  • Sitemaps.
  • Schema.
  • Caching.

Neglectingto pay attention to detail

Noneof these mistakes are particularly complicated or difficult to avoid. Yousimply need to be aware of them, implement a plan to avoid them, and pay closeattention to detail.


Leave A Comment