There are some web developers who do their best to “lock in” a client so that it’s hard for the client to leave them. There are standard practices to follow because they’re… well, standard. They make sense and they’re good from a future-proofing and updates point of view. In the case of SCR, their original developer built them a website that looked good and did what the client wanted. So, happy client. Except this developer didn’t follow the standards when building this website.
Here’s what I mean, but this will take a while. So bear with me: Every WordPress (and Drupal, and Joomla, and…) website runs on what’s called a “theme.” The theme determines the look and feel of the site. Now, no one theme is ever perfect for every client, and so you make modifications to the theme to achieve the end result the client desires. There’s nothing wrong with that. However, making changes directly to the theme’s files means that you can never update the theme, because an update would erase those customized files, replacing them with the theme’s default/standard ones.
To get around that, the concept of “parent” and “child” themes was created. You basically “clone” the original theme, and that becomes the child. You then place your modified files in there, and you can still update the “parent” theme properly for updates, bug fixes, etc, and the custom files won’t get over-written.
Still, no problem there. Everyone likes having a secure website with all the patches and bugfixes applied. I sure do.
Here’s where we run into an issue. The original developer decided to stray from convention here, and change the name of the folder/directory that the parent theme resides in. While this doesn’t sound like a Big Deal™, it absolutely IS because it breaks the update functionality completely. If the update function is looking for a theme in a particular place, and it’s NOT there because the developer decided to be Clever™, then the system sees the theme as a totally custom one, not the one it really is, and the update can’t happen.
So SCR’s website is running on version 3.0.x of this theme in particular… and the current “real” version of it is 4.1.x. That’s almost 3 years of updates, patches, bugfixes and features that SCR was not getting for their site, specifically because the original developer made the choices they did when building the website. OH, and it’s not the most straightforward thing to fix, either, because when you create a child theme, the files it depends on are expected in a certain place (the wrong place, thanks original developer) and so there’s a bunch of code file edits to make to fix that.
Also, the developer built the site with like 5 H1 tags on the homepage, which is totally going to mess up their SEO because the H1 tag is “the thing” that the page is all about. How can you have 5 “the things” on one page, that aren’t the same?
The developer also didn’t configure the SSL certificate (the thing that makes your website “secure,” and shows the little padlock in your web browser to let you know it’s secure). As a result, the website for SCR could be found at both https://www.scrmemorycare.com/ AND http://www.scrmemorycare.com/, meaning that search engines (like Google) saw it as two distinct sites, but that were exact copies of each other. This is called “Duplicate Content” in the SEO world, and the end result of it is that the website ends up competing with itself on Google for position in searches.
While I’m not naming names, if there’s anyone who wants to know the company (they’re local to me here in The Woodlands, TX), I’m happy to respond to an email. In case, you know, they did YOUR site as well and you don’t even know how badly you got hosed.