markdown guide

WordPress works because it already has a massive set of plugins that can be used without the help of a developer. As badly coded as the platform is, the plug-and-play model just works and is irresistible to clients. With WordPress, clients can also manage their content themselves. SEO and marketing plugins just work out of the box. As a business, one can have a website with contact form, opt-in system, etc., within minutes, which would take days to code.

Ay the end of the day, there's very little business value in static sites.


This is wildly inaccurate and unrepresentative of the JAMstack ecosystem. I'd consider it downright naive to say there's "very little business value" in static sites.

Consider Gatsby, for example. This is an open source static site generator for React that recently raised $3.8M in funding and formed a business around static site development.

Or perhaps consider Contentful, a headless CMS popular in the JAMstack ecosystem. They just raised $28M in funding late last year.

If your clients are happy with WordPress, that's excellent. By all means stick to WordPress! Where I work, though, are clients are constantly demanding more modern toolsets and pushing the limits of what a website can be. For these clients, WordPress is not a solution in which they are interested. We work with Contentful, Gatsby, React, Serverless and more on a regular basis for some very high profile clients. I can assure you that these clients find substantial business value in these "static" websites.

We've come a long way from the previous generation of static site generators. With the ability to deploy highly dynamic, browser-based JavaScript applications to CDN's, the line between a static and a dynamic site has become increasingly blurred. Gatsby, for example, has started to move away from the term "static site generator" to avoid confusion here.

The clients with which we work are designing and requesting functionality that would not be maintainable were it implemented in a few hours with a suite of WordPress plugins, so reaching for these modern tools is much more feasible in my day-to-day work.

I strongly suggest reading up on some literature and case studies on jamstack.org/ or check out some of Gatsby's showcase to see just how much you can accomplish with these tools. You'll find sites with full login workflows, ecommerce, and more.


By "business value" I don't mean investors, but businesses themselves. I don't doubt the capabilities of JAMstack, but it remains a loosely defined term. WordPress follows a predictable architecture, and other than for any custom-made plugins, it takes no time to figure out how it works. This is important for the next guy who gets to maintain the system, as opposed to some stack that is built from MongoDB, React, and what not.

The clients with which we work are designing and requesting functionality that would not be maintainable were it implemented in a few hours with a suite of WordPress plugins, so reaching for these modern tools is much more feasible in my day-to-day work.

Believe me I'm happy to hear that. I'm not an evangelist for WordPress. It is poorly designed, and becomes a maintenance nightmare over time. But, for most of the business cases out there, it "just works", the talent is in overwhelming availability, and you can get started within minutes.

Now, that is business value, and no matter how passionate we developers are about the next big thing, it makes no difference to the business owners.

I feel compelled to repeat myself, since people seem to be getting the impression that I'm putting WordPress above everything else: Simplicity and speed are real, massive advantages that are hard to argue against. Sites like Disney run happily on WordPress. If you understand the client's use case or can tell them truthfully about talent availability down the road, then by all means use the JAMstack or even go full custom. But for God's sake, don't go about asking how to convince them to use your favorite tech.

I"m going to argue a different way in favour of the 'JAMstack'; I hate marketing buzz, but whatevs.

This is the business value from what I can see; I'm newer to SPGs, so I could be wrong, but it's my current opinion.

Static sites do the following:

  1. They are very very fast. Most WP sites that are setup on a budget are not fast and actually require hiring the right developer, not just 'any' developer to get it to serve quickly. Not the case with SPGs, if you can write HTML, CSS and JS then you are booming; it's very hard to make a slowly served site I'd wager.

  2. Clients think they can just slap in a plugin and get a rocking; this is why wordpress is slow and they don't know who to call or what to do and they are channelling money into SEM and SEO and losing money there hand over fist; this is a huge value.

  3. The code tends to be more easily read. This means if they call me up and say 'hey Roger can you create an xyz or do xyz', often I can do it in an hour or so and it's still fast and it's still easily read by the next guy.

  4. Backups are built into the system al a github/git.

  5. Security issues are basically null. In comparison to any surface like WP, effectively using Hexo, et all is a zero risk scenario.

  6. Price. Outside of tools like Contentful and their type, the pricing is as close to $0 as you can get, which means I'm getting the lions share and that is good for me and good for my investment in good customer service.

Important caveats:

  • With Netlify and CloudCannon content management is included and no longer an issue of paying some over charging headless CMS provider extortion rates to just serve content.

  • Most SPGs come with Let's Encrypt and CDN built in and not as a value add either.

Honestly I'm very happy to have finally sold a client on a SPG and while down the road they may need to include a more diverse solution; today it'll be a great launch site for them handling so many potential scenarios without additional work on my or their part.

PS. This doesn't at all dismiss wordpress; that would be silly to say one over the other, just simply that SPGs have a ton of value and are very valid from a business use case.


I'd argue against there being "little business value" in static sites.

  • They're 10000x more efficient than their server-rendered counterparts since they can be purely served off a CDN. You get less bandwidth costs and immense scalability with static.
  • Your site is 10000x more secure because it's run off a CDN, not a server, so there's no much malicious code that can run. And even if there was some scrupulous client-side script, it'd be difficult to slip through, since content is controlled (Markdown only basically). No issues with a client installing a rogue plugin that runs mining operations or bloats the DB.
  • Since most deployments are through Git, your site is version controlled, allowing you to step backwards to a previous state, easier than a Wordpress backup.
  • You can still serve your static content from Wordpress as an API, and benefit from the flexibility of it's content structure (like using ACF).
  • Your SEO can be handled completely, like Yoast in WP. It's simply setup by the develop when they optimize the website (often using react-helmet and Markdown metadata).

It really depends on the client. If your client is looking for a product they can iteratively develop themselves, sure, Wordpress and a slew of plugins will work. But those clients probably aren't dealing with scaling issues, or honestly, they don't know what they want and the site's quality will suffer regardless.

At that point, they're not looking for a website, as much as a theme builder. Those are the clients I could recommend Squarespace or Wix and they'd probably be more satisfied with the greater degree of control. and honestly, being cheapos who want to install a plugin for a contact form instead of paying a dev to do it


It really depends on the client.

Yes, sir. And that's my main beef with this article. The OP is asking how to convince the client that static websites are best for them, whereas this decision should be based on a rational and far-sighted analysis of their requirements.

being cheapos who want to install a plugin for a contact form instead of paying a dev to do it

Really? Is that your stand?

I'm all for empowering clients. But when you've worked as long as I have, you've probably come across some clients that will nickel and dime you for services.

The kind of client that gets upset over charges for "updating the website" when you have to spend time swapping text and images they're indecisive over (and wanted moved around 3-4x). The same client that'll often insist to do work themselves, or in some other cases, outsource labor to cheaper places, and in even worse cases -- come back with broken code from that cheaper dev and ask you to fix it.

I'm not saying every client is like this, but I will say that these are the clients who prefer "simpler" plug and play solutions like Wordpress. It's the kind of client that doesn't respect your time as a professional. The same kind of client that'll pervade any service industry (like plumbing, car detailing, etc).

Again, we have to put things into perspective. Maybe the client is a WordPress user and knows that a simple plugin can solve the problem for the time being. And maybe they aren't a WordPress user, but a simple plugin does cover the use case.

I agree about the existence of such clients, and I personally make a run when I smell bullshit on the table, but the point here is not the ethics of clients but making the right decision.

Yes, sometimes static site generators make sense, but you have to be sane about your decision making.


I would argue against the "clients can also manage their content themselves". As someone who has been a part of a group for 3 years. They are techno-phobic, yet willing to trust an outside vendor to manage their website including login credentials and personally identifiable information of their users.

If they could allow themselves to not have a login feature and just post their content publicly, a static website would serve their needs greatly and would reduce the cost of having someone "maintain" it.


Well, most of the time business requirements extend beyond posting content publicly. I'm aware of the pain WordPress brings, and in one my earlier projects I was supposed to build an e-commerce system, first in Java (yay!), but then they changed their mind to PHP (oops!). I got started and was about 25% done, when the SEO and marketing folks started crying about how long it was taking for "simple" things like double opt-in and Google Analytics ecommerce tracking, tracking the path a user took in a funnel before dropping off, etc., which could be set up and working in five minutes in WordPress. At that time, I couldn't argue with them. With WooCommerce they could be selling stuff the next day, and there was tremendous business value in that. For the record, I moved out soon afterwards (for some other reasons), and they ended up picking Magento. 😐

I can agree with Ankush. Wordpress just works. It's not perfect, but works. Bussinesses don't have years, they need it ASAP. Nothing can beat WP in that.


I would disagree. All those things could be done in SPG. It takes time and knowledge, but it is worth it if performance and security are a requirement.


Performance and security are poorly defined and definitely overrated. Are you telling me no WordPress installation is safe from hacking? Or that no static website can be hacked? And what about performance? I currently maintain a WordPress website that sees 2 million visitors a month, and it all works well on two load-balanced servers of 8GB each, with about half the RAM free most of the time. What more "performance" do you want from a website/blog?

The developer's enjoyment is not the only point of view. At the end of the day, those of us in consulting are paid to provide the most optimal solution for the least possible cost. I'm all for coding chops and intellectual amusements, but we should reserve these for personal projects. Just look at how you've phrased your question: How do you convince a client . . .

Really? If you've understood their use case, you can sell the right solution to them, provided you understand it too. Wasn't it a better way to start by describing their needs and then searching for a solution?

Fair point. But you forgot there are clients that need smaller websites with smaller budget for development. You cannot say SPG is not good choice for those clients, IMO.

smaller websites with smaller budget

I think you've really got it backwards.

Assume I'm a small client with a very tight budget. I want a fully responsive website with (or without) a blog management software and integration with a few analytics tools. This can be done within half an hour in WordPress, and there's a good chance I can find someone who can even do this for free.

How do static site generators even compete? I'll need a developer to add another page next time, and there's no way I can ever add any dynamic functionality if I ever need one later on.

Please explain how that delivers me the solution I need, faster and in a smaller budget?

Use this and you have a full funcional site in matter or minutes:

Let's stop here, because we are not on the same page. Let's agree that we don't agree.

Yes, we should definitely stop. Overexcitement is the bane of our industry.

Can I just hop on here to say that this is the most gloriously civil end to a discussion that I've ever seen on the internet.

I hope you were not being sarcastic. 😂 Anyway, there's no point in arguing beyond a point. We need people who refuse to tow the line and persist with new technologies and ideas, because ultimately they bring the change. Today this is happening with the Elixir community (and maybe even Serverless and NoSQL), and a decade down the line we'll all be thankful for it.

(100% sincere, no sarcasm here.)

😇 Cool, because I was pretty damned worked up during that exchange. 😛

Today this is happening with the Elixir community
That Elixir is better than everything else? I do admit, it looks like a nice language but that probably because I like Ruby.

Again, "better than everything else" is a fallacy. Some techs are fundamentally better at some things than the others, but mass adoption is also important. Elixir is a near-perfect ecosystem for web development, and it's waiting for enough Ruby businesses to cross over.


I don't know much about SPG admittedly, but I know a lot about wordpress websites and specifically how to optimize them.

There is virtually no performance difference with the core platform. Performance is only sacrificed by unnecessary plugins for one function, bloated themes with built-in page builders, and poor image/code optimization by the designer/developer. What you save in milliseconds by building a site statically is instantly wasted by longer development times.

In terms of security, every site is at risk. Wordpress, when managed properly, is just as safe as a static website. With plugins like WordFence you could even argue it's safer because I can easily blacklist suspicious IP's.

With all of that being said, if I ever want to do things a specific way I have simply just said this is the best way. I'm the developer, I'm the one building it, my clients pay me for my expertise and knowledge. It's literally that simple.

Well, static sites, like microservices and single page applications, are the cool new thing. Who wants to deal with "boring", age-old stuff like WordPress?! The other day there was a post about using a nothis package to remove the need for this from JavaScript. I can only shake my head . . .

My first boss said it best, "I use the language and platform that makes me the most money."

Yes, and I wish more developers took off their kool-aid glasses before making technology decisions. Ongoing support, ecosystem and availability of talent are major, major factors.


Coming to this thread a little late, but I have recently had to answer this question many times over, so I decided to do a little googling and arrived here...

First, I think the discussion here went a bit off the rails. Some people went down the path of "use the right tool for the job," which is valid, but irrelevant to this thread. The situation I find myself in more often is the client is a candidate for JAMstack, but that means they are also a candidate for Wordpress, how do I convince them to buy my product? The fact is these tools both get the job done but I work faster and deliver a better product in a custom, modern tool chain. So, if you want me to build your website, then these are the tools I use, and I can give this to you with exceptional service, fewer compromises, and at a good price.

In the end, you are the product, not the website. So when I sell a client I sell myself first. So when we arrive at the question of CMS to use, the tension is between wanting ME to build it but not wanting to use something they haven't heard of.

Here's the thing, I don't do Wordpress, or joomla, or drupal ever (anymore). I don't have to make every website on earth. I spent the better part of my early career wrestling with these CMS's, and they worked well for me back then. The issue is, most clients quickly learn they don't want to mess around with design as much as they thought and are constantly calling for tutorials on how to edit the navigation or to add a tag or how to edit something I had to hard code because it wasn't something the CMS supported out of the box.

Then I got DDoS attacks on wp-login pages, databases that weren't backed up, or had to deal with a purchased template that didn't work 100% on the version of PHP they were running on some cheap hosting provider. I even had a template that used to mysteriously wipe the custom CSS for no apparent reason. I've spent hours trying to implement a design that a friend of a friend gave to a client, frustrated at the fact that I knew I could hard code it in thirty minutes if I didn't have to deal with making it totally editable in this CMS or work with X plugin.

Then I got used to version control, continuous deployment, automated testing, and at last found Contentful. I got used to an easy CDN for images that handled all sorts of manipulations as well as being able to do full re-designs later on without ever having to migrate a database or deal with hosting. Clients were actually editing their content only, they got exactly the design they wanted, for the budget they set out for. They were happy and so was I.

The fact is I don't need to build everyone's website. And if someone comes to me that really cannot live without Wordpress I'm happy to point them in another direction. But if you want my team and I to build your site it isn't going to be with Wordpress. I will work my ass off to get you exactly the design you dreamed about and will make sure that you are satisfied enough to never want to go with another developer.

There's a lot of talk about business in this thread without actually talking about a customers number one business need. A reliable, consistent developer that delivers a super fast, awesome website and can be called on over and over again to deliver updates. My advice to you is sell yourself and your company first to the client, then use whatever technology helps YOU deliver on the best possible service to that client.

After reading this thread I realized there's a million technical reasons to not use Wordpress anymore, but very few that clients understand, because what they are buying is a service not a website.

Whether or not there is immense business value in a specific site architecture is the wrong argument to have. There is immense business value in having the right person or team do the job and do it right the first time. I craft websites now that are always backed by a headless CMS but may or may not be JAMstack compatible but I constantly remind myself before every pitch the technology is irrelevant right now, make sure they buy the team first.


Great point of view. I agree 100% about selling yourself and your services first. I don't see a problem in working with WordPress, mainly because I am rarely in charge of the backend, database, or security.

Thank you for the great response.


I dont get it, you are the professional, you should decide which solution is the best.

Anyway you can just lay out the advantages of not having a server, which are costs and performance, low complexity and cheaper.


I haven’t done a lot of client work but I’ve definitely had some hair-pulling interactions where they had heard about some random technology or wanted me to use the same stack some other project is using for completely arbitrary reasons.

I’ve learned how to really get this out of the way early. Lay down the law in this regard.


That is precisely my point, which advantages, how to present them, and so on. I am a professional, and I know all that, but I am interested in how others do it to help others, not just me.


Ah I see, then you should have started with how you solved this problem in the past, what worked and not, then others can add extra info.

I am sorry for the misunderstanding.
Do you have anything to share now that you know the intention of this discussion?

No sorry, I was just trying to put myself in your shoes and that is all I came up with.
I stopped doing freelancing and working with the end customer many years ago, I felt like I will live less if I kept doing it 😁.


I spent the last two years championing static sites using SSGs and a variety of headless CMSs in a marketing agency. We ultimately came back to WordPress because our clients requested it and there's a lot of value out of the box. However, I still wanted the benefits of static sites (speed, security, scalability).

That's when we found a service called HardyPress. They host WordPress in an anonymous environment that goes to sleep when you're not using it. A static version of the site is deployed to a CDN when you're ready to publish changes. It's been the best of both worlds for us.

You do still have to think about what it would mean for your WordPress site to be static. Not all plugins will work. HardyPress does provide support for Contact Form 7 and search.

I have no affiliation with HardyPress. I just think it's an ingenious idea.



I haven't heard of HardyPress, but I will take a look at it.

I know about projects with Wordpress REST API as a backend with static page generators. This is similar approach, I think.

Thank you for sharing.


Yes, the WordPress REST API is another option, but it isn't used with HardyPress. You build your site like you normally would (besides not being able to use every plugin) and it deploys a static version of your WP frontend. Yes, this means your templating is still done in WP. We settled on using Timber to make that part less painful. :)



How do you convince a client to a static website?

I show them the benefits, whether it's the savings on hosting/bandwidth costs, or the lightning fast load times of static vs server-side. I also show them the process of adding content, and managing the behemoth.

If by the end of the short presentation they're impressed enough, we go static! If not, I lean towards more common solutions like Wordpress.

It also depends on the situation. I'm obviously assuming the site benefits from being static. If it was a dynamic community site like dev.to, I wouldn't recommend static. It's easier to recommend when there are pros to outweigh cons.

What are your favorite players?

NextJS is great for simpler projects with a few, non-dynamic pages (/about vs /blog/).

GatsbyJS is fantastic for generating larger static sites with dynamic pages. Since Gatsby loads all your content during development and runs the build process, it can generate physical static pages for anything you need. So you can take hundreds of Wordpress blog posts and generate real HTML pages.

Netlify CMS is an admin panel for static websites. It seems to be the solution to brining a human element to static sites, since most are deployed via Git using Markdown -- not the most non-dev friendly process.

I haven't tried it yet, but Jigsaw looks like a great static site option for PHP/Laravel devs.

Solutions like Gitbook, Docusaraurus, React-Styleguidist, etc -- all do an excellent job of creating a (nearly) zero-config build process for documentation. Drop a Markdown file, or run a CLI, and you've got yourself an entire documentation website, looking slick and styled.

Do you have any tricks or tips you want to share?

Make lots of boilerplates (or find/clone some). Most SSG solutions are great, but they're far from fully featured out-of-the-box. GatsbyJS for example has plugins for sitemaps, RSS, etc -- but you have to install and configure it for each project.

Having structured projects for certain situations, like documentation, make the process of rolling out another static site so much easier.

  1. Using a headless CMS, (check out Sanity or NetlifyCMS) my clients actually feel empowered to edit the site content, knowing that they can't muck up the design or flow of the website.
  2. No plugins, core, or theme to update – saving my clients $$$ in maintenance costs.
  3. The obligatory comment about performance, security, and free hosting.

But obviously – like others have stated – use the right tool for the job (even if that means resisting the urge to use Gatsby for everything).


How do you convince a client to a static website?

Security :) (and no update every week like Wordpress or Joomla)
Performance is a good point too.

What are your favorite players?

I use Pelican (only because it's Python and I can read the code/develop plugin)

Do you have any tricks or tips you want to share?

Just an advice: if you never tested static sites and if you are affraid to be limited by markdown syntax, some plugin/extension allow personnal syntax to be exported in your own html.


A genuine question: how far you can go in your experience? Do you know of any really complicated website made with JAMstack? Since your a Wordpress developer, any pro and cons between the two approaches?



As I already stated in this comment, I have developed websites on Jekyll, Middleman, Hugo, and Hexo so far.

The most complicated website that is built on JAMstack that I know of is Smashing Magazine.

In my opinion, Wordpress and SPG are two different worlds. The first one is a global solution with an enormous amount of themes, plugins, and solutions. In the last couple of years, the platform moved forward, and it has many great features, but there are still too many options, settings, and cluttering. SPGs are unique, they could be developed specific to users needs, they could be extended by some customizations, plugins, shortcode, etc. But delivering content over CDNs as static files, that is powerful. And it could be free if you are using Netlify free plan.


I recently moved a bank from sitecore over to netlify, algolia, contentful using Gatsby and react.

The biggest selling point? Cost, security and flexibility.

Moving to jam stack offers huge potential for the future I reviewed all of the architecture patterns and with the bank wanting their content produced once but available anywhere it made real sense to move away from a tightly coupled traditional CMS.

One huge benefit of headless and the JAM stack is the incremental movement you can make.

We started out using just the static website and blog posts, product info and other content was all produced in markdown files. This got us to a point of replicating what we had without needing sitecore. It was also insanely fast without any database connections and Gatsby handling the build.

After that we added in contentful and removed the markdown where appropriate.


Had this conversation recently of static sites VS something like Wordpress, and the truth is, at the end of the day, clients really don't care about technologies, they care about scalability, SEO, posts, and Plugin support. Using something like Gatsby for static site generation isn't the best solution unless you use Netlify. In conclusion, using static sites without a service like Netlify is a huge NO.


Yes, I am using Netlify for every project.


You don't sell them a static website, because that sounds lame. You sell them a professional website with optimized loading and rendering performance and improved accessibility and SEO compliance, which is - what an amazing coincident - most easily achieved with a static web site and maybe some progressive enhancement with javascript.


How do you convince a client to a static website?

You shouldn't have to. If you do, though:

  1. Perfect security thanks to no non-static code on the server.
  2. Awesome performance because nothing has to be calculated.

Static Sites are cheap and secure.

My Favourite is Hugo, because of performance even with thousands of pages.

Use 3rd party api for authentication and comments etc.. Like Auth0 and Disqus


I think static sites have a much lower barrier for entry for many clients, especially when they just need simple feedback forms or contact pages. I made a static hosting service for my classmates to use for their web projects. We weren't taught about deployment as a part of the class, and they needed an easy way to get their projects online.

Thus, dragdrop.site
I was kinda inspired by Glitch, but they needed a way to upload static files that they'd already written, and allowing them to drag files into the browser to deploy to a site is a pretty cool experience.


If a site does not have Dynamic parts or they don't really want to update content themselves you don't even have to SELL IT.

The real benefits I see on general is
1) the site can be as fast as it can be as it needs no database lookups at runtime
2) best security as there will be no login functionality to be compromised
3) Those can probably translate to reduced maintenance costs depending on the automation you set for the deployment workflow and the frequency of deployment

EDIT: Just realized the post was from last august


Every comment counts. Thanks, Giorgos! 👍


So far, clients asked me to build them a static website.

I have built websites on Jekyll, Middleman, Hugo, and Hexo. I cannot say which one is my favorite, but I must admit that Hugo is fast.

Here's my two cents:
If you are using Netlify, you could add code snippets, like tracking snippets, right from Settings -> Build & deploy -> Post processing -> Snippet injection:

Post processing — Snippet injection


I fully agree with you, but I'd rather Hexo. It's more flexible than Hugo. Jekyll is very popular, because it's supported by github, but it's slower than Hexo and Hugo. I would also like to try a GatsbyJs that becomes more popular


Well, sometimes you cannot choose. I am using Hexo for my website, but if a client wants a website on Hugo than you build the website on Hugo.

Also, I don't know which one is more flexible, but I managed to fulfill all client's requirements no matter which generator is in use. If you have problems, the community will help you. For example, I had a problem, posted it on Hugo Discourse, and got an answer in minutes.

You are absolutely right. But if you do your own projects you don't need a clients ideas)) And that's why I like Hexo. It's more friendly with themes and plugins ;)


A static site could be run on CDN like netlify for free.


I don't get it : when you click on getting started, there's nothing about getting started but about best practices :)


You can sell it on safety. Tell them about security benefits.