My business demands that I maintain a website, but I make no claim to being a web design expert. I help people write books, I’ve always thought that was enough to be getting on with, and so I’ve always reserved this space for writing-centered advice. However, after recent events nearly crippled my site (and having to spend the better part of May dealing with that), I believe that sharing my experience may help some of you defend yourselves and your sites against menaces like the Sneaky Bastardy of WordPress-based scam artists.

My story begins in late April, when I hired a developer to make some updates to The Writing Texan. I logged in to the WordPress side of my site to create a login for him, and discovered an account I had never created. It included an e-mail address from my domain and Admin privileges. I know I didn’t authorize this! I thought. So, I did what you’re supposed to do. I deleted it, changed my passwords, and immediately called my hosting service (Tech Support Call #1) to inform them. They assured me I had taken the right steps, and reminded me to check often for WordPress updates, as hackers often use outdated code as a back door.

So, Lesson #1: Update all of your WordPress themes, plugins, etc., as often as possible. Try to check weekly, if you can.

Now let’s jump forward to May, when my developer–let’s call him Dev–starts work. I am pleased with the changes overall, and things tick along merrily for about a week. Then, without warning, I lose access to the WordPress side of my site. My login simply stops working, I can’t reset my password, and I can’t get into my site. I notify Dev, and he tells me to wait until he’s done with his changes, then we’ll see. So, I sit on my hands until he lets me know the site is live, and I try again. No go. Now I’m starting to get twitchy. But before ripping anyone an unnecessary new one, I decide to educate myself on the problem. First, I call Tech Support (Support Call #2), then I start searching the WordPress forum. Turns out it is a known issue, but there is no single fix that always works. I go back to Tech Support (Support Calls #3-5), and their diagnosis suggests that Dev has utilized too many redirects. Aaaand Trust Issues rear their ugly heads. Have I hired the wrong guy? Am I throwing good money after bad if keep using him? I call a friend who’s much more design/WP savvy than myself and ask for her advice. She encourages me to give Dev a chance to fix it. Then she tells me that she always sits down with a new designer/developer and asks them to talk through any problems they foresee in working on her sites. Every developer has a personal style, a way of writing code, and it is not the same as anyone else’s. So, any time you bring a new person in, there will probably be some incompatibilities in the code.

And, voilá, Lesson #2: Always ask a new designer/developer “What problems do you see emerging from changes to this code? What is your approach to fixing potential incompatibilities or glitches?” 

After two additional weeks of anxious waiting (as the alliteration indicates), Dev lets me know he’s fixed my access to the site. The problem, he says, was not the redirects themselves, but a WordPress virus buried in the theme. I go back to Tech Support (Support Call #6), who reply, “Meh. Possibly. But not likely.” Hey, at this point I’m just happy to have access again. The doctors can disagree as long as my patient is on the mend. And all is well for a few days.

Then I get an e-mail with the ominous subject “Hacked.” A random fellow named Mike has sent a short note to let me know my site has been linked to a fake Amazon phishing scam. So, I contact both Dev and Tech Support (Support Call #7). Both advise me to ignore him, as the e-mail is likely a scam itself. But now I’m antsy, so I do a bit of research on the source e-mail and the guy. He has social media profiles, pictures, a couple of half-constructed blogs. Not impressive perhaps, but enough to suggest he might be a real guy. So I reply and ask Good Citizen Mike for details. Over the course of the next 24 hours, we exchange multiple e-mails and I gather enough data to confirm that my site has, indeed, been hacked. I can see the fake page. In the process, using some fiddly google search techniques, I find two other pages that lead to gobbledygook on my site, plus evidence that some guy I’ve never met has uploaded some of my code to his site for purposes that remain unclear to this day. Crud.

Next stop, Tech Support (Support Call #8). I fill them in on what I’ve discovered. They find and quarantine the erzatz Amazon file, but have nothing illuminating or helpful to say about the gobbledygook or code lifting. In the end, all the rep can say is that hackers often exploit WordPress vulnerabilities to plant any variety of malicious code on unsuspecting sites, so update and change passwords often.

And so I extrapolate Lesson #3 (perhaps the most important of the lot): Your site is vulnerable in ways you never imagined and cannot predict. Be vigilant, educate yourself, and act quickly. I nearly dismissed Citizen Mike’s warning because my resident experts told me not to worry. Now I’m glad I decided to follow up. I might never have come to direct harm from having my site borrowed in that infuriating way, but I’d prefer not to find out.

Do I now feel I have completely gotten over on Sneaky Bastardy? No. Whether your cuckoos are ill-intentioned hackers or well-meaning coders, the only real way to keep site-wrecking eggs out of your online nest is to become a coding expert and examine all of your files on an ongoing basis. That is not a viable option for me. And it probably isn’t for you, either. Instead, I have made a priority of internalizing the three lessons above: update often, communicate with your coders, and act boldly to defend yourself. Because there’s no room on your website for someone else’s agenda.