If you’re running a business, you’re probably spending a lot of time thinking about money, and how to save it. That’s a good consideration, however, there’s a difference between being fiscally responsible, and simply going with the cheapest possible service at the expense of quality.
As WordPress security experts, we’ve seen firsthand the consequences of hiring a junior front-end developer simply because their rates are cheap. These front-end developers are likely not fully versed in development best-practices from performance and cybersecurity standpoints, and they probably don’t have access to a dedicated team of security professionals to guide them. It’s the blind leading the blind — the younger developer lacks the experience to build a good quality website, while the business owner lacks the experience to know a slipshod website when they see one.
We have no issue with junior developers. Everyone has to start somewhere, and building a few okay websites is a necessary step toward learning how to build great websites. Template-and-plugin WordPress websites can be fine for personal use, startups, and early-stage companies. But most businesses need a website that is optimized for responsiveness, security, privacy, and accessibility — as well as SEO and other marketing-related requirements. These factors require a bit more knowledge and experience to get right.
A Story of Inexperienced Developers and Unsecure Websites
We’ve had a handful of clients in the past that have hired junior developers — often younger family members or friends — to rebuild their site. We get it. It’s cheaper and the company gets to support the career development of someone they know. However, as security experts, this always raises a red flag for us.
We know that a lot of people coming fresh out of technical schools or web design programs understand the basic building blocks of web design and development. In fact, you can make a fair living by just downloading WordPress (it’s free and still the most popular CMS on earth), installing a theme and some plugins, and populating the theme with words and images, over and over, for various clients. “Entry-level” developers who work this way might seem attractive to price-sensitive owners of small and medium-sized businesses.
That aside, there’s a lot more going on behind the scenes of any website that these junior developers just don’t have as much experience with. What’s worse is many freelancers and junior agencies stay in that superficial space. And this is the latent risk that we see cropping up in the marketplace. There is a growing pool of talent entering the workforce who have the skills to build and launch basic sites, but who lack the experience and knowledge to secure them. There are no regulations in the field of web development, and most beginner web development programs offer very little training for even basic security and performance standards.
These junior developers aren’t certified by a board or regulatory body. They aren’t formally licensed or ticketed. They’re not obligated to apprentice with a senior developer for any period of time. Imagine a huge pool of young, unlicensed, and uncertified carpenters building cheap houses for whoever was willing to pay. Now imagine the kinds of problems those houses would have.
This isn’t just speculation — this is something we see firsthand. Here are the 23 most common problems we see with WordPress sites built by junior developers.
- Relying too Much on Plugins
Websites are complex beasts, and plugins are designed to make things easier for both the developer and the website owner. Ninety percent of the developers in the world are going to use plugins for at least some of the functionality that a modern website needs. Junior developers are able to build functional WordPress websites in part because:
- A lot of WordPress plugins are completely free
- Most of the functionality that a website requires can be fulfilled using plugins
But just because some plugins are helpful, doesn’t mean they all are. All plugins are developed by third parties, but the level of support and technical expertise that goes into them varies wildly. Inexperienced front-end developers tend to rely too heavily on plugins to do things that more experienced developers can do with just a few lines of code. A plugin may serve the right function, but it will also introduce a whole bunch of extraneous code, which impacts site performance.
The other problem here is that junior developers often don’t have the time or experience to properly vet these plugins before installing them on the site. When we audit sites, we often find plugins that are in use which have been abandoned by their original developers. Many of these plugins are riddled with security vulnerabilities. Using these plugins on a site basically puts a target on your back for hackers. Unfortunately, junior developers don’t know any better and aren’t skilled enough to provide better alternatives.
- Failing to Consider Existing Traffic and Rankings
Google doesn’t care that you have a fancy new website. Search engines follow their own set of ranking factors — a sophisticated algorithm guided by cutting-edge machine learning. If you have a nice new site, you’ve probably revised the sitemap, that is, moved menu items around, changed content, removed articles, added new products, updated your team bios, etc cetera.
You need to let Google and other search engines know about all of those changes. And the only way to do that is to:
- Create a new sitemap in a format that Google can read
- Submit that sitemap directly to Google Search Console
- Create 301 redirects for any pages in the old site that have been (re)moved
Junior developers often miss all three of these steps. The odd few will get #1 right. Very few get #3 right because, frankly, it’s difficult, and it sometimes requires writing redirects into an htaccess file using Apache… which is nobody’s favourite language. Unfortunately for junior developers, creating 301 redirects is actually the most critical task in retaining rankings and helping to reduce the number of 404 errors your site experiences. We see a lot of neglect when it comes to 301 redirects, and this can really hurt your rankings and traffic.
- Poorly-Worded Metadata
OK, we admit, this isn’t security-related. But a fundamental part of developing high-quality websites is the metadata. Metadata (page titles, page descriptions, URLs, header titles) is one of the oldest, most consistent search engine ranking factors These data points show up as the titles and text blurbs you see in the organic (non-ad) results for a Google search.
Junior developers often neglect metadata entirely. While WordZite doesn’t provide SEO or digital marketing services, a lack of optimized metadata appears in our system as a big drop in traffic shortly following the launch of a new site. That may precipitate us investigating a hosting or firewall issue only to find out Google has dropped a site off the rankings because of an SEO issue.
- Disabling Firewalls
At WordZite we’re always stressing the importance of a well-configured firewall. We use two — one at the server level, and one as part of our CDN. We do understand why a developer might want to disable a firewall while working on the site. We acknowledge that a CDN like CloudFlare may hinder your ability to refresh the site and see your updates in real time. And if you happen to be working from an unfamiliar IP address, the firewall can also inadvertently lock you out of the site. A developer might temporarily disable a firewall to make their job easier, but this speaks to inexperience, and maybe a bit of laziness. We never disable firewalls on live websites except during brief periods of testing or in response to a reported incident.
- Not Using a Staging Site
When developing or rebuilding a part of a site, we recommend using a staging copy of the website. A staging site is hidden from the public, on either a subdomain or a separate server from the existing site. This means that we can leave the live site and firewall untouched during the development process, so the site stays secure. We’re yet to find a junior developer that does this, simply because it’s another hurdle that requires a bit more technical finesse to accomplish.
- No Backups During Development
We’ve seen cases where junior developers will spend hours and weeks building a new site. And all of a sudden, something happens and the site gets destroyed or deleted. The cause of such a tragedy is too often human error — much like deleting or forgetting to save that precious spreadsheet. It happens, but this is why experienced developers take frequent backups during the development process. When we’re in the midst of a heavy development cycle, we’ll take daily, or even hourly backups of a site.
- Disabling Two-Factor Authentication
Much like firewalls, two-factor authentication (2FA) is another important security measure we recommend to most clients. Disabling 2FA leaves the site open to brute force attacks and other potential vulnerabilities. We’ve seen junior developers disable this simply because they don’t want to have to pass the 2FA step when they login. But a couple extra seconds while logging in can save you hours of remediation down the road.
- Using Weak Usernames and Passwords
We recently audited a site built by a junior developer wherein all the core logins were changed to the username “admin”. As anyone with even basic cybersecurity training will tell you, “admin” is one the most hacked usernames on the planet. Changing all the logins for a website to the same simple username leaves you wide open for a brute force attack. You should never have to compromise security just to refresh the look of your website.
- Adding Multiple Admins
We’ve seen cases where a junior developer will enlist the help of even more junior developers or sub-contractors. We’ve also seen cases where multiple staff members at an office decide they want to take a crack at redoing a site. And thus, multiple admins are added to the site with full access and no access controls, permissions, or policies in place.
What are the chances that everyone in this situation is using 2FA with a strong password and username? What is the likelihood that the site is configured to time out users who are idle, or block users who have made 5 failed login attempts? Generally, we recommend restricting WordPress admin access to as few people as possible.
- Using Cheap Hosting
The kinds of business owners that are apt to invest in low-end developers are also very likely to purchase cheap hosting. In the world of hosting, you get what you pay for. A cheap web host will have dozens, even hundreds of sites at the same IP address, all sharing the same server resources. This is bad because any one of those sites could develop an issue that would quickly impact the rest of the sites on that shared server. For that little bit of extra peace of mind, we always recommend paying a few extra bucks for quality hosting.
- Poor SSL Encryption (or No SSL Encryption)
SSL encryption is the method used to scramble data that is transmitted over the internet. This type of encryption prevents third parties from intercepting the data in transit, and reading or tampering with it.
Most data shared on the internet is pretty benign, but some of it is highly sensitive — think of all the online options out there for banking, filing your taxes, or submitting insurance claims. Sensitive data should always be properly encrypted. We’ve seen cases where SSL certificates and methods of encryption have not been implemented properly or fully across the entire site, which is enough to keep us up at night.
- Mishandling Personal Information
Encryption is just a piece of the puzzle. How certain information is handled and stored is also critical. We’ve audited countless websites where all form submissions (most of which are general inquiries about products and services, containing names, email addresses, and other data) are saved directly to the website database.
This is bad. If the site ever got hacked, that company would be liable for the breach of all of that information. A better approach is to send these submissions into a Customer Relationship Manager (CRM) or email them to an administrator. Never save this information to your WordPress database. It’s just not secure enough.
- Not Mitigating Comment and Form Spam
Spam is a fact of life in the internet age. We all get email spam. But we also see spam in the form of comments on blog articles as well as fake submissions to contact forms. Junior developers often overlook this as something that just happens, but an experienced developer will know that you can minimize spam — and that doing so will help to secure your site. While you can never eliminate it 100 percent, programs like ReCaptcha and Akismet provide simple, workable solutions.
- Plagiarism
We don’t see this often, but we have seen one case where a client’s logo was very clearly plagiarized from another company. The freelance designer they’d hired had simply taken someone else’s logo and swapped out the colours. Content is also sometimes plagiarized by lazy developers, or those that promise to write content in order to land a contract, only to later realize that writing good quality web content is actually a significant undertaking. Legalities aside, plagiarized content almost always gets noticed, and it can lead to your site getting delisted by Google. Trust us: a good copywriter is worth investing in.
- Formatting a Site Poorly Across Devices and Resolutions
One of the more obvious things we notice when we’re auditing a site that was built by a junior developer is that it starts to look a bit wonky when displayed on different screen sizes and devices. A junior developer may not have the resources or experience to adequately test a website on every possible screen size and browser.
At WordZite, we’re more concerned about security than looks, but it’s worth mentioning that a site that isn’t optimized for every device is going to perform badly. This means dramatically increased load times for users, and potentially even broken or non-functional elements.
- Not Optimizing Images
Speaking of load time — high-resolution images are beautiful, but they’re the bane of anyone trying to optimize the speed of a WordPress site. It takes a trained developer with experience working with a wide range of images and placements to know how much an image can be resized and compressed before it starts to look bad. We adhere to set standards that we’ve developed through years of research across the entire industry. The first step is to crunch all those old images down to a size that is acceptable for their placement on the site (in terms of both file size and dimensions).
- Issues with Caching and Compression Configuration
Once an image file is resized, it then needs to be properly compressed and cached.
Compression is the process of shrinking a file down to a smaller file size. Most people have probably heard of a .zip file. Websites use a very similar technique. Good servers and CDNs will compress images, documents, and other files before transmitting them to a browser. The browser will then uncompress those files so the user can view them. This reduces the amount of data that needs to be transmitted, and thus speeds up the load time of the site.
Another technique that improves performance is caching — in which certain files are saved by the user’s browser, so the browser doesn’t need to query the server to get those same files over and over again. A junior developer may not have the expertise to properly configure and enable these types of performance-enhancing features. And that’s not even mentioning minification and CDN-level caching.
- Haphazard Launch Processes
We’ve had a couple experiences where a client had their own hosting, but was relying on us for security and performance monitoring. At some point, they had a junior developer launch a whole new website on their server, overwriting the existing website without taking a backup, and without informing us.
We catch this type of problem immediately because our monitoring system sends us a bunch of notifications and alerts. In both cases, the new site had a range of issues, including but not limited to:
- SSL encryption
- Caching
- Compression
- Security monitoring
- Firewall
- Virus scans
- Redirects
- Error logs
- Formatting
- Integration with third-party applications (eg. social media)
- Admin password strength
These issues were not obvious upon viewing the front end. The sites were an improvement aesthetically. But Google, and other applications like virus scanners and security services, can see these technical deficiencies. Left unchecked, they can contribute to a massive dip in the site’s search engine rankings. Google penalizes poorly built websites, and in extreme cases, users might get security warnings popping up in their browsers saying that the site is “unsafe”.
All of this could have been avoided if the developer had a proper launch checklist and QA process. Truth be told, most don’t. So that leaves us to take action. If it hadn’t been for our security monitoring, these clients might not have noticed anything wrong until months down the road, when they realized that they were not getting any sales or leads from their beautiful new website.
- Taking Email Offline
Sometimes DNS changes need to be made when a site goes live. Your IT team has a lot of sensitive DNS records configured for mail servers, file sharing, and other technical infrastructure. It’s not a place to muck around unless you know exactly what you’re doing. Despite this, we’ve seen junior developers go ahead and change the entire DNS hosting without informing the IT team. The result: you wake up on a Monday morning with a beautiful new website… and your email has stopped working. And now your world is on fire because you can’t communicate with anyone. It goes without saying that we don’t recommend allowing a junior developer to make DNS changes without consulting with an IT professional.
- Not Keeping Error Logs
Websites are built on a stack of technologies. Many things can go wrong, and they frequently do. Monitoring and error logs are the data sources that allow us to see what happened, when it happened, and potentially, why. When we have this information, we can take action to remediate the issue and ensure it doesn’t happen again.
Experienced developers will build in a process during launch and post launch to check and review the logs and monitor various metrics to make sure the site is performing as expected in the live environment. It’s one thing to have a site that loads well when only you and your boss are looking at it. It’s another thing entirely to have a site that gets a huge spike in traffic and still performs. We believe that uptime monitoring and load time monitoring are essential (see #22). We also like reviewing error logs (especially 404 error logs — see #2).
- Not Implementing Change Monitoring
Another post-launch nice-to-have is change monitoring. We recommend this as it allows a developer to closely monitor what files and folders are changing on the site. Obviously, the developer will know what is being changed as they are working. But in rare cases a file may change because of a WordPress or plugin update, or in rare cases, because of tampering by an unauthorized party. Change monitoring is a very basic service, but having it in place ensures that the developer can take action immediately if something is being modified that shouldn’t be.
- No Uptime or Speed Monitoring
This kind of performance monitoring is something that Google can also provide through its Analytics platform. At WordZite we have our own services in place to monitor how quickly sites load, on average, for users in various locations. We also have a service that notifies us within seconds if one of our sites goes offline.
Both systems are a bit delicate and can report false positives. But we think that a few false positives that turn out to be nothing are far and away preferable to getting an email or phone call from a client telling you your site is offline. That is not only embarrassing, it can also lead to a big loss in new and repeat business. A junior developer may not realize just how crucial this type of monitoring really is, until it’s too late.
- Disregarding the Complexities of Ecommerce
Finally, we want to caution against using a junior developer for something as complex as ecommerce. When you’re dealing with sensitive information such as addresses and credit card numbers, you need a secure, tested platform and a developer who knows their way around it. This is no place for cheap plugins and shoddy development practices.
We’ve seen one case where a client launched a site with ecommerce functionality that had not been properly tested. Their junior developer was relying on one plugin to do everything, without any formal training on ecommerce or credit card security. This was pretty much guaranteed to lead to problems. If we have a client who is working with a junior developer, we generally recommend building the site on a platform like Shopify. Shopify is a good option because they manage the core platform, leaving the front-end aesthetic work to the junior developer — part of why Shopify is significantly growing their market share. There are good WordPress ecommerce plugins out there, like Woocommerce, and they do have more robust functionality, but they require more expertise.
In Summary
We want to reiterate that we have no issue with junior developers creating websites. The issue arises when businesses decide to rely solely on an inexperienced front-end developer to build a website that requires more finesse; more awareness of security and performance issues.
An in-depth understanding of web development takes years of training and experience — and yes, hiring an experienced senior developer (or a team) will cost more than hiring someone fresh out of college. But the highest cost of all is the opportunity cost for a website that’s been compromised or has been dropped or delisted by Google. The loss of traffic, leads, customers, suppliers, and partnerships can equal tens or even hundreds of thousands of dollars.
If reading this makes you reconsider the safety of your current website, get in touch with us! We’re always happy to audit and even launch a site that has been designed and built by a junior developer.
