WordPress powers 40% of the web. That does not make it right for your site.

WordPress itself is not bad for SEO. It can handle the clickable headlines and short summaries Google shows in search results, your site map, and the signals that prevent duplicate-page confusion, all through popular SEO add-ons. The SEO problem that shows up in practice is about structure and speed: a theme with a drag-and-drop builder and eight to ten add-ons frequently produces pages that take two to four seconds to appear on a phone, and Google factors page speed and stability directly into rankings. Slow pages rank lower. A hand-coded site with no add-ons shows up in under a second by default and passes Google's health checks without a fight. There's also a control difference worth naming: on a custom site, every behind-the-scenes label that tells Google what your business is (your identity, your offerings, your common questions, your navigation trail) is written by hand to match exactly what each page is. With WordPress, you're limited to what the SEO add-on lets you toggle and what the theme author wired up. In most niches the gap is manageable; in competitive local search markets, both the speed handicap and the precision of those labels compound over time as Google leans harder and harder on how the page performs.

A typical small-business WordPress setup runs $400–$1,000/year: hosting ($10–$60/month), a premium theme renewal ($50–$200/year), and two to three plugin licenses ($200–$600/year for forms, SEO, security, backups), before developer hours for the update cycle. A custom site on Core hosting at $60/month runs $720/year flat: no plugin licenses, no theme renewal, no compatibility debugging. Over five years, a $1,200 custom site totals $4,800; a comparable WordPress build with $500–$700/year in compounding overhead totals $4,300–$6,300 depending on maintenance. Custom lands at the bottom of that range: ahead of a diligently maintained install within five years, behind a neglected one. What matters is $4,800 is fixed while WordPress climbs every renewal cycle. Run the five-year number before deciding.

Not without touching code. A hand-coded PHP site has no admin panel, no visual editor, and no dashboard for non-technical content editors. Changes go through the developer. For most small service businesses — a plumber, a law firm, a physical therapy practice, a cleaning service — this is not the operational constraint it sounds like. Those businesses update their site three or four times a year at most, and the Care or Priority managed hosting tiers, which include up to one (Care) or three (Priority) hours of content edits a month, cover that easily within the monthly fee without requiring you to log into anything. The constraint becomes a problem in specific scenarios: a business publishing multiple blog posts per week, a franchise with non-technical location managers who need to update their own pages independently, or a product catalog that changes daily. If you can describe your content update workflow specifically, who edits what, how often, and on what schedule, the platform question answers itself. If the answer to "how often will I use the editor?" is less than twice a month, you are paying for a built-in content editor that managed hosting with included edit hours handles without the maintenance burden.

Yes, significantly. WordPress powers roughly 40% of all websites (as of mid-2026) on the internet, which makes it the most-targeted website platform by a wide margin. Automated bots constantly hammer the standard WordPress login and admin pages on every site they can find. This isn't theoretical; it shows up in a site's logs as constant background noise even before Google has indexed the site. Most break-ins trace back to flaws in add-ons rather than WordPress itself. An add-on installed on 400,000 sites with a serious flaw will have ready-made attack code circulating within a few days of that flaw going public. Any site that hasn't installed the fix by then is exposed, and add-on developers vary widely in how fast they respond to security reports. A custom site has no WordPress login page for bots to hammer, no add-ons with known weak spots, and no admin pages for bots to find. Upkeep boils down to keeping the server software current (something that comes up maybe once every year or two) and making sure the code handles incoming form data safely. That's a fundamentally smaller and more manageable target.

Difficulty scales directly with how much content there is. A five-to-ten-page service site with no large blog archive moves over cleanly: copy the content, rebuild the pages cleanly, keep every web address exactly the same (or set the old ones to automatically forward where anything changes), and re-register the site map with Google after launch. For most service businesses this is a few hours of focused work, not a multi-week project. Sites with a large blog archive (hundreds of posts, unusual content types, online-store order history, or customer accounts) need more planning. WordPress can export its posts in bulk, and those can be brought into a custom site; the work scales with the volume. The one rule that matters most: keep the web addresses the same. Any address that does change needs to forward automatically to its new home before the switch goes live, not after. Forwarding preserves the ranking power those old links built up; dead-end addresses throw it away. Google flags any new dead ends within days of launch so they can be fixed before any ranking damage sets in.

The typical WordPress site built with a popular drag-and-drop builder takes two to four seconds for the main photo or headline to show up on a phone, and that's exactly the kind of speed Google scores when it decides rankings. That's on standard budget hosting with no speed optimization. On higher-end hosting with paid speed tools and a network that serves your site from near each visitor, you can get below two seconds with steady effort. A hand-coded custom site with no builder and no add-ons generally shows its main content in under a second without any of that. The difference is structural, not a hosting quality gap: a page built with one of these builders hauls in a big chunk of the builder's own behind-the-scenes code on every single page visit, no matter what the page contains. You can cache it, but you can't remove it without ditching the builder entirely. A hand-coded page loads only what it needs. The same speed work you'd do on a custom site — shrinking images, serving files from nearby, loading scripts later — produces better results from a cleaner starting point than the same tricks applied to a WordPress build that's heavy before you even begin.

You own a custom site more cleanly, fewer strings attached. WordPress ownership is real but hedged: you own the files, but they only run atop an active database, a compatible WordPress version, supported server software, and add-ons at matching versions. Move to incompatible software untested and things break; let an add-on license lapse and its features become a security hole or stop working; a theme can stop working after an update if its developer walked away. A custom site needs one thing: a standard web server, no database for a typical marketing site, no add-on compatibility chart, no platform version to sync. Any competent developer can read the code, not just a WordPress specialist. Moving hosts means copying files and pointing your domain at the new server. That's clean ownership.

WordPress wins where frequent self-managed content is non-negotiable: a news site publishing daily needs a built-in editor, scheduling, and separate writer logins out of the box. A membership site with non-technical editors, a store where the client adds products weekly, or a multi-author blog with independent contributors: WordPress's built-in editing solves a real operational problem worth the overhead. The mistake is applying that logic to a ten-page service site updated three times a year. WordPress earns its complexity in direct proportion to how much the editing gets used. If "how often will I log in" is "rarely," that system is overhead, not capability.

With enough effort you can get close, but you're fighting the build instead of working with it. Getting a builder page under a second usually needs a paid speed tool, a nearby-serving network, scroll-triggered image loading, and several other tricks set up correctly on higher-end hosting. Even then, the builder's own code still loads on every page; you can cache it but can't remove it without ditching the builder. A hand-coded site starts with none of that weight, and the same tricks produce better results from a cleaner start. The tools cost money too: licenses, developer hours, an image-optimization subscription, paid monthly to approach what custom gets from day one.

Neglect compounds risk monthly: expired plugin licences stop security patches, and incompatible themes or plugins can make patching break the site, trapping it on old versions. Sites neglected 12–18 months are routinely breached through outdated add-ons before owners notice. An unattended custom site carries almost no risk: no exploitable add-ons, bot-targeted login, or update treadmill. Content ages; the site stays secure. That gap is why WordPress costs more than its sticker price.