The Pitfalls of Clients Writing Web Content

"We'll do the writing."

I dread hearing those words at the beginning of a web project. No matter if the project has been in non-profit or higher ed, internal groups writing their web content has always been a point of contention for the project.

Why?

Control and skillset. It's is as simple as that.

The internal group has the expertise and wants to write the words on the web pages, but should they?

Good writing and good web writing are two different things.

In any web project, the goal is to launch a successful website on time and budget, but what's the point of doing all that work if the website does not answer the questions that your intended visitors seek? All that money, time, and effort is washed down the drain.

I know that a reliable team of content producers (I'm extremely lucky to work with such a team in my current job) matched with a strong content strategy equals a winning plan, but I've been involved in many web projects where convincing clients of this has been challenging.

No matter how much data you show about the importance of search engine optimization and the need for simple language on a web page, friction always comes about over the content. Most of the web projects I've had to project manage hit this roadblock.

Tell me if this sounds familiar:

All parties agree that good content is needed. In the worst-case scenario, the clients provide the content, and it not only scores low in search engine results page (SERP), but it's really long and densely written.

If you're lucky to have content producers on the team, they can rewrite the content for the web.

I've been in this situation and here's where you hit a roadblock:

The clients are vested in the content, they want what they want, but the truth is that the words they provided are not adequate for modern search engines, and the pages will perform poorly.

What I've found to be the best of both worlds (and what causes the least amount of problems) is a simple model to navigate through difficulties.

Have the client designate a key point of contact for your team. The client's leadership trust this person and is essentially becomes the day-to-day champion for the project. They're willing to get into the weeds and bridge the gap between what their leadership wants and what's a good outcome in terms of the writing.

Schedule weekly calls with that person and work with them. Listen to them and bring them in on the web project. Let them see the sausage being made behind the scenes.

Yes, that means they'll see rough drafts of the content, the site's wireframes, and design mockups. The trust that's built over time solidifies and enables you to work with them on setting up key milestones with their leadership.

The big win here is that there's a big difference between the external team saying: "Your content needs work" and the internal champion saying that.

No one wants to hear that their writing isn't up to par.

But if you work with a data science partner to score the content for how well it'll perform in Google search, you come bearing a gift. The writing isn't poor because you feel that way, but rather the words are not signaling the search engines in a way that will drive traffic to the page.

That's a key point.

Building a website is a complex project that takes patience, collaboration, and a willingness to be open-minded.

The most effective projects I have been part of all come down to trust. Trust that the writing will result in pages that can easily be found in search. There's a big difference between a page being found on page one of search rather than on page five.

To sum up, when starting a web project with a group, I'd recommend:

• Show the data on the value of having professional content producers write the web pages.
• Advocate for a point of contact from the client be your counterpart and set up weekly calls with them.
• Build trust with your point of contact and let them see the whole process, warts and all.
• Agree on a workflow for the content, write it down, and have both parties agree on the process.
• When you hit a roadblock, work with your point of contact, explain why (with data and research), your team recommends a change in the content.
• Be open, listen, and be flexible.

Even after you follow all of this, do not be surprised if the client's leadership (or an unknown stakeholder that pops up out of the woodwork late in the project) disagrees with the direction that the content is going.

When this happens (and on some projects it will), talk with your internal point of contact. Strategize on the best path forward and advocate what's best for the project by backing it up with research.