Warning: preg_replace(): Compilation failed: invalid range in character class at offset 4 in /home/customer/www/nicmitchell.com/public_html/wp-content/plugins/crayon-syntax-highlighter/crayon_langs.class.php on line 340
A Tale of Hosting Horror at GoDaddy Managed WordPress | nicmitchell.com

A Tale of Hosting Horror at GoDaddy Managed WordPress

Posted on Jun 12, 2015

This is a cautionary tale for those of you thinking about using GoDaddy Managed WordPress. I have a client who was hosted on Media Temple Managed WordPress. My client had a number of things in her GoDaddy account, GoDaddy had purchased Media Temple, and the GoDaddy plan was actually a little cheaper than the going rate at Media Temple. So we transferred her site from a Media Temple account to a GoDaddy account, though in theory they are the same Media Temple servers.

I really wanted this to work out because of the convenience to her, and I also really wanted to see GoDaddy do something right for once. So I gave it more than enough of a shot to see if I could make this work. Here is a detailed account of the ways in which GoDaddy created pain in my world.

Migration from Media Temple

Originally hosted at Media Temple, this migration was enormously painful. One might assume that it should be easy considering they are owned by GoDaddy, and I was informed that the GoDaddy Managed WordPress is already using the Media Temple servers and DNS. However, I could not use the automated migration tool. I was informed by support that it would not work. It was designed to work over FTP, but I could only access Media Temple’s servers via SFTP.

I also could not use the Duplicator plugin to migrate the site, which I have used successfully for years. Even when specifying the port for MySQL, I could not connect to the database using Duplicator. I reached out to the Duplicator author to ask for advice. He said that custom port numbers are not usually a problem and can be specified when connecting. I don’t remember exactly how I resolved this, but I think I eventually threw my hands up in the air and had to hardcode the values to connect to the database directly into the Duplicator plugin.

SSL Installation

Considering that the SSL was purchased through GoDaddy, DNS is shared between Media Temple and GoDaddy (as I was informed by support), one would think that this process should be pretty straightforward. I have manually installed numerous SSL certificates on VPSes myself, so I am familiar with the process. However, it took about a full week to get the SSL installed. Not only that, but something was wrong with DNS. Ultimately, this meant that my client’s site was down for an entire week while she was trying to run a business.

I contacted support numerous times to correct the issue and got different answers each time. What truly baffles me is that when the SSL was initially installed, apparently nobody verified if the installation was actually successful, which it clearly was not. Navigating to the site produced a browser error that the server could not be reached and suggested a security error. Upon researching the specific error, this was presumably because there was a problem with how the certificate was initially issued.

However, my suggestion informed by the browser’s own error messages seemed impossible to the numerous support reps I spoke to. They kept suggesting that either I did something to mess it up, or I just had to “wait it out” and I was supposed to believe that it would magically fix itself. I was essentially told that I had to be patient and wait the 48 hours that it takes for GoDaddy to do complete these installations, despite the fact that we were well outside of that timeline.

Regardless, in the end, they did have to end up reissuing the certificate. This was after a week of the site being down and my client trying to run a business. Not only is that unacceptable, in retrospect, I can’t believe that nobody offered to waive at least a month’s hosting payment or provide any sort of redress for such terrible service.

Clueless Support

Support at Media Temple leaves much to be desired. All one can do is open a support ticket and wait around 12 – 24 hours for a reply. I would usually get a response from a general tech rep who really had no idea of what a managed WordPress environment meant. GoDaddy was a step up in that I could always get a hold of a support rep 24 hours a day. That’s great, but none of them had any real understanding of what a managed WordPress environment entails either.

Having just taken over these servers from Media Temple, they seemed woefully ill equipped to dealing with the specifics of what is going on. I’ve been working with WordPress since 2008, and I am rather familiar with the problems that generally come up. What I don’t know is how this managed environment works behind the veil (supposedly the benefit of it being “managed”).

The tech reps have what seems like three stock questions they ask about, which are things that I already know about and have checked. There is a deeper problem going on than what I have access to address myself, or else I wouldn’t have contacted support to fix it. In other words, if I have contacted support, I am 110% positive that the problem is not on my end or accessible to me.

When I finally get that point across and they respond with “Wow, I’ve never seen this before. This has never happened,” that’s a pretty good indication that you should escalate this issue (and probably not consider me to be the average clueless business owner who breaks their site and calls in for tech support to fix it). I was informed that the only way they have to escalate an issue is to open an internal support ticket (that I am not copied on) to an engineer or technician. They told me there is no way to expedite the handling of that ticket, despite the fact that I had been waiting for multiple days for somebody to 1) give me any viable answer to my questions, and 2) listen to the feedback and knowledge I currently have about the problem.

I also had reps say that they take notes on everything I called in about, but none of the reps seem to READ the notes of others. I have to explain the entire situation all over again every single time.

I was told I would receive emails with an update of the status. That never happened.

When I called to check in on the status and explained the entire situation all over again, I was informed that the technicians/engineers did not work on the weekends, and that I would have to wait until another business day rolled around before I could see any progress. And even when that day rolled around, I had to respect the fact that there were other tickets in front of mine that would receive priority.

Unpredictable Performance

One of the benefits of a managed WordPress environment is that somebody else sets up Varnish, caching, CDN, and all those other server optimizations so I don’t have to deal with it. However, this site would inexplicably slow down at random times. It was unpredictable in terms of time of day, time of week, etc. The site was not receiving a huge amount of traffic, probably 100 visits per day maximum. It would slow down in the middle of the night too when I was doing maintenance, so I know it was not a traffic spike issue.

Considering this is technically a shared environment, it is possible that resources were being eaten up from other sites on the network. But when I called support to inquire about this, they had no viable answer. Essentially they didn’t believe me and said the problem was not on their end. I’m sure they believe that. The tech rep suggestion is that I run Google PageSpeed and perform those optimizations.

I already did that. This isn’t my first WordPress rodeo. The site was well optimized.

Whenever I use Pingdom or something similar, it is showing the server response time to be sometimes between 3 to 12 seconds. Optimizing images and minimizing files is not going to affect the server response time. That is not an issue on my end.

Core WordPress 404s

WordPress core files would produce 404s. I’m sure this affected speed and performance as well. But randomly, when watching the DevTools console, admin-ajax.php would show up with a 404. Sometimes it would be other files as well, but this cannot be something that I’ve done to cause core WordPress files to be unreachable. There must be something happening with how GoDaddy is trying to cache these resources that is backfiring and making them unreachable.

Custom Post Type 404s

This site was using WooCommerce products, and it also had a couple custom post types. Randomly and inexplicably, the site would serve up 404s when navigating to products or other custom post types. I could fix it by resaving permalinks. Then it would happen two days later. Then again three days later. There was no discernible pattern.

I had installed Stream so I could see the behavior of other people using the site. There was no behavior that should have had any impact on permalinks or custom post types. Posts and Pages were no problem, but custom post types would randomly stop working. Calling tech support, unsurprisingly, again yielded zero helpful information. According to them, this was clearly a problem on my end, despite it being a problem that I have never experienced on any other host ever.


I love having a staging environment to test plugins, test site changes, etc. I love the idea of having it be “one click”, so I can deploy and overwrite a previous staging site and start fresh. However, the staging site should actually work like the main site. With GoDaddy, whenever I cloned a site to staging, it would not clone the custom post types.

That means WooCommerce products (of which there were hundreds), as well as orders and the multitude of other custom post types that were not copied over. When I talked jumped on tech support chat to figure out why that could be, the rep said something about reassigning database permissions. Again, I don’t know how the internals of this infrastructure works, so I was willing to give her the benefit of the doubt. After waiting more than the allotted time I was instructed to wait, I tried cloning to the staging area again. No good. I still do not have custom post types.

Don’t Do It

Eventually, I just couldn’t do it anymore. I had sunk way too much time into this and was getting terrible results for my client. Media Temple has a pretty good reputation in general, and I though that using Media Temple’s servers even with GoDaddy’s name should probably turn out okay. That’s why I was willing to put up with some of these things, because I actually held on to the idea that it would get better.

It doesn’t. Save yourself the trouble and don’t buy into Media Temple or GoDaddy Managed WordPress hosting. GoDaddy and Media Temple failed miserably, and I eventually migrated this site to WPEngine, where I know my expectations will be met.

Submit a Comment

Your email address will not be published. Required fields are marked *