Building a Successful Content Site

Building a content web site and making it successful is not like “Field of Dreams” wherein “if you build it, they will come.” First of all, just building isn’t easy. Even if choosing a platform proves a simple decision, you’ve only gotten past the easiest part. Generating good content on a consistent basis is an extremely difficult task. This applies whether you are creating content on your own, for example via a blog, relying on employees or contractors to write that content for a commercial site or relying on volunteers, as I have, to generously contribute content to your site. Even once you’ve created great content, that doesn’t mean anyone will ever see it. This gets even more complex if you have financial or marketing or other goals tied to your site. Even success brings its own complications in terms of managing your community or ensuring that your site remains available even under heavy load. It also brings increased expectations that can become hard to meet.

Over the past years, I’ve had a range of success in these areas, first many years ago with my blog, then with my prior work on the Adobe Developer Connection and, most recently, with this site. In this article, I will share some of those successes and the things I’ve learned from them over the years in the hopes that this can help you. I will also share my failures and the lessons I am still trying to learn from those in the hopes of helping you to better avoid them. Much of the discussion will focus upon my recent experience with this site but will also draw upon those prior experiences. All of these apply to sites with multiple authors, whether external or internal, while I think many, if not most, can even apply in some form to running your own blog.


Before I get to the ugly part, I’d like to share the areas that I think have made my site a success in a relatively short period of time. In each of these areas, I think I could still improve, but I also think I’ve done well enough to count them a success nonetheless. We’ll start with where I think I’ve had the most success down to the where I think I’ve been mostly successful but still could significantly improve.


Getting readers to know your site exists is possibly the single hardest thing to do. When you are launching a new site with no brand and no reputation, as I was, you cannot rely on Google, social media or other typically dependable traffic sources to necessary send people your way. First, you probably don’t have enough content to drive any consistent amount of search traffic. Second, it is unlikely anyone will be linking to your content. Third, you don’t have an existing audience to rely upon to help generate any sort of buzz on social media. In my personal experience, automated tools to push your site to various promotional outlets and social media are useless. Thankfully, though, there are other ways to build that audience.

Over the years of promoting content, I have developed a strategy that works for me. While it requires a good deal of manual work and relationship building, I’ve found that it pays off. The first part is the easiest, and that is working through various sites that give you an outlet to promote links to your articles. For example, in my topic areas of web and mobile development, I rely on sites such as Hacker News, Reddit, DZone, EchoJS, Lobsters and Tech.Pro. If you are in a different topic area, do some research and learn about similar sites that you can use.

Every one of these sites will differ in terms of the type of community, the amount of effort they require and the potential (or type) of payoff. You’ll need to take some time to learn both how to use them, how their community works and whether they are worth the time and effort. For example, in my case, Hacker News takes minimal effort and can have a huge traffic payoff, but only certain types of articles do well and only infrequently (and if they do, you need to know that much of the discussion will happen on the HN comment thread and not your own). On the other hand, a site like Tech.Pro take a bit more effort (requiring an article summary at a minimum) and, at the moment, have a small (though improving) traffic payoff. However, just because a site has a low direct referral rate, doesn’t mean it isn’t worthwhile. For instance, in this case, Tech.Pro reaches some big influencers in my community and can be useful in indirectly building a buzz on other outlets such as social media. Of course, learning these nuances will take time and experience.

It seems obvious that you will want to build a presence on social media, having outlets you manage to promote your content on Facebook, Twitter, LinkedIn and Google Plus, for instance. Which one works best for you will likely depend on your community. For example, Twitter is the single biggest source of traffic for me while Facebook and LinkedIn are useful but not significant. Google Plus might seem initially insignificant but I’ve found that relying on a profile or page isn’t useful. Instead, post your content to relevant Google Pus communities and you may find more success. Also, don’t forget to add your links to StumbleUpon as it can provide a decent and consistent stream of traffic. Finally, don’t push your article to every site at once, spread them out over days and, if one is successful, let it play out before pushing something else. It rarely matters to the success of the article that it shows up on these sites a few days after it actually launched.

The last resource I’d suggest is to build relationship with influential community members. For example, people who run popular blogs, newsletters or events in your topic area or those that have large social media followings. Remember though, I said relationship – which is a two-way thing. Don’t simply broadcast your stuff to these people and expect them to respond. If you have ways that you can help them, do so. Make sure you know what they are up to and read their stuff as well – don’t just expect them to be responsive to yours. Never expect them to include your content but make it easy for them to do so (for example, provide them the links with summaries as necessary in the same format they publish them in). Lastly, if you are fortunate enough to have a means of supporting their site, newsletter or event in some manner through sponsorship or donations, do so when possible. I am not suggesting anyone can be bought off, as sometimes what you give doesn’t have to be financial, but every good relationship in every aspect of life relies on giving as well as receiving.


High volumes of lower quality content is the quick and easy road to boost your stats. It is also, in my opinion, a dead end, as you will inevitably lose the trust of your readers (leaving you to find ever new and more gullible audiences to survive). Creating quality content takes time, effort and patience. Not only does a good article or tutorial take more time to write in and of itself, but quality content also requires that every article be reviewed for accuracy, copy edited for grammar and consistency, tech edited (if necessary), and carefully produced. Good content also takes patience because it frequently doesn’t have the immediate traffic payoff that you can achieve with “link bait.” However, good articles stand up over time and continue to drive visitors long after their publication.

Part of ensuring quality is creating a process that content goes through. This means that each item is put into a queue for proper review and tech editing, then copy editing and then production, before finally going live. In my case, as I have no staff or budget to rely upon, all of these are done by me, but that doesn’t mean I didn’t still follow the process. I’ve found Trello to be a good tool for managing and monitoring this process. It is simple enough to be quick and easy to use but just powerful enough to get the job done. For example, my Trello board might have stages for:

  • Ideas and discussion: these might be topics under consideration that don’t yet have an author or topics that have an author but no commitment (as in deadline) yet;
  • In Writing: as you would expect, these are articles that are currently in the process of being written by an author and, very importantly, have a deadline, even if it is loose or has the potential to change (mine, for example, are all tentative since my authors are all, essentially, volunteers);
  • In Tech Editing: Not all types of content need to be “tech edited” but they all should be checked for accuracy in some manner before moving on. If necessary, these might go back to the prior status for revisions by the author;
  • In Copy Editing: if possible, hire an experienced copy editor but, regardless, someone with excellent writing skills should be checking every article for spelling and grammar. Do not rely on the original author to do this for you;
  • In Production: these articles are ready to go, but might need formatting and design within whatever system you choose to publish with;
  • Launched: this category can be useful for tracking feedback or changes that might be needed post launch, in the short term.

Even if you are simply publishing a blog of your own content, having even a simplified version of this process could be worthwhile. Finding tech editing or copy editing might prove challenging, but try asking friends, family or colleagues whom you trust to at least look over your work before you publish it.

Author Outreach

This item might be better titled, “Treat Your Authors Well.” I’ve been an author for years even before running this site and I can tell you there are certain things that will ensure that I will avoid writing for you in the future. These are:

  • Overbearing copy editing or multiple revisions: While copy editing is necessary, make sure that you keep the authors voice. Overbearing copy editing makes everything sound bland or in the voice of the copy editor. While for some authors (for instance, those for whom English is not their native language – assuming you are publishing in English) this might still require a lot of copy editing, the key to keeping it from being overbearing is that it retains the author’s style, voice and, where applicable, humor. Also, you handle copy editing, don’t send it back the author to be done. Significant corrections to accuracy should be handled by the author, but fixing grammar, formatting or spelling should not;
  • Taking forever with feedback or publication: the last thing an author wants (especially if they are not paid), is to have you sit on their article without feedback of any sort for weeks or even months. You can seriously compound the problem if you take a long time only to ultimately reject the author. If there is a reason for a necessary delay, communicate that. If there is a technical review process before an article is accepted, make it timely and ensure that the author knows what the process is and how long it will take. Keep them updated regularly on the status of the article in that review process.
  • Making changes without letting the author review and approve them: obviously, an article can change, sometimes dramatically, as it goes through copy editing and production. However, always ensure that your author has the opportunity to review the article as it will look on the site before it goes live.

If you rely on external authors, whether paid or unpaid, and you treat your authors well, they will want to write for you again. They may also refer others to write for you as well. If your authors are internal to your company, they will be happier in their jobs and likely put more time and effort into their work for you. Your site depends on good content. Good content requires good authors. Good authors are hard to find, so treat them well.

Internal Community

Until relatively recently, I would have considered this a failure on my part as I had no internal community to speak of. My relationship with all of my authors was one on one. The authors did not know or even necessarily know of one another, nor did they have a means of communicating. However, realizing that I had close to eighty extremely talented writers and developers who’d contributed to my site, I finally realized the untapped potential there. I started a mailing list (via a private, invite-only Google Group) for my authors and it has paid off beyond my expectations.

Nowadays, I use the list to share upcoming, but not yet publicly published, articles on my site, giving my internal community a chance to provide feedback on articles while also having the chance to get a first look at stuff before anyone else. I also solicit articles when my content pipeline is low, discuss topic ideas or simply allow authors to share ideas or conversations of their own. While I try to keep the volume of emails low so as not to be a burden, I have been very excited by the level of participation. Having a mailing list of this sort also keeps you in authors’ minds when they are considering writing new topics. I also think there is the potential to build this internal community even more through other channels. Even if your authors are all employees, building a sense of community among them will likely pay off dividends in the long run.

In fact, this very article was the idea of one of my authors suggested via my mailing list.


Next I want to look at those places where I think I have failed so far as I believe they contain just as many lessons, if not more, than where I’ve succeeded. We’ll start with what I believe to be my smallest failure all the way up to my biggest.

Content Pipeline

As I said earlier, it is important to have a process in place to ensure that your content is high quality, thoroughly reviewed and flows consistently. This is easy of you have reliable (and paid) resources to author content. For example, if you are doing this for your company where employees are dedicated in some manner to writing for the site or you have the budget to secure authors (and hold them to deadlines), this becomes a much easier task. At that point, simply make sure you’ve put in place a good process to:

  • Ensure that you know what content is coming and when (and I recommend having a consistent publication schedule rather than publishing ad hoc);
  • Properly copy edit and tech edit (if necessary) every article before it goes up;
  • Keep track of what stage each item is at within your content pipeline;
  • Monitor comment activity and traffic on articles after they launch.

In my case, without a budget or employees, I was dependent on the generosity of authors willing to write or contribute their content for free. This meant a lot of time was going to (and continue to) be spent securing articles to publish, which meant I was often still trying to secure articles at the last minute (or filling gaps personally). It also meant I had to be loose on deadlines since the authors were not paid. In this sort of situation, it is better – in fact necessary – to have too much in your pipeline rather than run the risk of having too little. While I have been successful in remaining consistent in the publishing every week and even increasing the number of articles from two to three at a minimum each week, I have not yet been able to avoid being dependent on all of this still happening very last minute, which is why I count this still a failure – if only slightly.


When you launch, you will probably not have a lot of content, but that will quickly change. Making sure your readers can find content on your site once this does change should be something you give a lot of thought and planning to ahead of time, keeping in mind that some aspects of this change and grow organically over time regardless. Your home page is important, but there’s the potential to over-focus on it. A majority of your readers will actually find your site via direct links to your articles, whether from sources like social media, RSS, and email newsletters. Your goal is twofold: first, to try to get them to explore your site beyond the initial article and second to get them to come back again in the future.

Getting readers to go beyond the initial article is mostly a matter of helping them find relevant content that they might be interested in based upon the content that they are reading. This can be done by showing related articles and by ensuring that you have a good taxonomy for your content with a navigation that allows them to quickly and easily explore other content based upon that taxonomy. I have failed to do the former. My various attempts to find plugins that do a good (and attractive) job of serving up related content has repeatedly hit a dead end. My suggestion is to plan for this from the start, even if it means manually tracking and maintaining related content at first (this is a time consuming process to attempt after the fact).

After the first six months or so of running this site, I did revamp the navigation based upon my taxonomy and saw a consistent traffic bump (though I can’t guarantee that was actually cause and effect). Despite the fact that my topic area is relatively simple, this could be improved. For example, wouldn’t it be nice if you could find all articles on more specific technology categories like Node or Angular, rather than browsing through a broad JavaScript category.

As for bringing readers back, this involves giving them ways to keep up with newly released content on your site. Newsletters, RSS and social media are all effective means of doing this, so you just need to make it easy and obvious how to subscribe to these things, particularly from your article pages. I’d grade this site a “C” on this front. Things I’d like to see would be an attractive (though not overbearing) and obvious way to subscribe to these channels at the end of every article. Also, I’d like to find a way to disentangle my personal social media from the site’s social media without losing some of my existing audience.


This site currently runs on the same Linux VPS that has run (and still runs) my personal blog (as well as my wife’s blog) costing in the range of $60 a month, which I feel is relatively inexpensive. As most of you can probably tell, it is simply a standard WordPress site. Under typical load, the site holds up very well. However, a successful article on Hacker News, Reddit or even relevant content newsletters like JavaScript Weekly, can often take the site down temporarily, costing potential audience. My host is generous enough to max out my CPU’s and RAM under these circumstances, but this is a reactive response happening after the site has already gone down (and I don’t mean to imply any blame on their part).

There are several potential solutions to this problem. The first is that there are caching plugins for WordPress that can both increase the response time of pages and the load on the server. The second is moving to a cloud hosting service that can scale better under load. My advice would be to put both of these in place before you even launch, as making these sorts of changes on a busy site is far more difficult. Unfortunately, I have not had the time to adequately research, test and implement these options, meaning that uptime continues to be a problem for my site.


This is probably one of the first questions those of you wanting to build a content site may have. But this is also the last item on my list because, unfortunately, this is the single biggest failure on my part so far. Despite a brief single sponsorship, I have, as of yet, failed to monetize the site at all even with the continual growth in popularity and traffic. Part of this is a matter of (arguably misplaced) principles and part simply a lack of time. The principled part is that I refuse to plaster my site with Google Ads. I’ve had experience with AdSense before and I was always left with the feeling that I was giving them way more than they gave me, as in, I’d deliver a lot of views and they’d pay me pennies or less for them. I’d much rather leave the site clean of ads than to trade that space for clutter that delivers trivial money. Nonetheless, finding other revenue streams or sponsors takes a lot more time and effort and all of my free time that could be devoted to my site was focused on finding, editing and producing content.

While I can say that, in the coming months, I am focused on figuring out a way to monetize the site, I don’t yet have any answers or advice to offer. Rather, I’d be seeking that. This was a passion project for me, not a business idea, so I didn’t start out with a business plan. Obviously, if you plan for your site to be your business, then have these sorts of plans thought out and investigated before launch.


As you can see, while I am proud of the success I’ve had building and running content sites, I also have a lot of areas to improve upon. Whether you are building a new site or looking to improve your existing site or whether your site focuses on technology or some completely different topic area, hopefully some of my experience will help you in the future. Despite any setbacks or failures, I love this kind of work as it continuously presents new challenges and opportunities to learn, from the articles my authors provide, from reader feedback and simply from the experience of building and running the site.

If you have any experience that you’d like to share with building your own site, feel free to share.


Doing More with Sass’ @each Control Directive

Using Media Queries in JavaScript