Structured Content for Marketers and Managers

Structured content is a term used to describe a suite of techniques that organize, describe, and format content in ways that improve it's value to readers and publishers.

These techniques give power to publish content across multiple channels, dynamically link items, and scale-up a site as traffic and content count grows.

Structuring content is not a single action. It is also not owned by a single team or role within an organization. Structured content only exists when the needs of viewers, authors, and developers are considered and balanced.

The end result is an approach that provides high-quality material to visitors while allowing authors and developers to be as productive and focused as possible.

Structuring content is a three-step process, each focusing on a different actor who is involved with the content. After the first pass, the structure must be adapted and updated based on changing audience needs, author tools, and technology advances.

Thankfully, the hard part is getting started. The maintenance is made easier because of the structure.

The three-foci for structuring content:

Any content structure project that neglects one of these will fall short of potential.

Summary: The output of an audience-focused phase is a list of content types, how each serves the audience, and how the content types relate to each other in ways that benefit the audience.

The first phase of structuring content is the most important: considering the audience's reason for visiting and how the content can be arranged for the audience's convenience.

Market Research & User Experience

Every marketer I know says that market research and user experience (UX) work is important. However, from personal experience and discussions with peers, it's clear that research and UX are rarely funded in a way that builds solid customer profiles, digs into what content is most meaningful, or asks what is lacking with current content.

Fiscal concerns might prevent this from being done. A lack of a clear strategy for content might be a contributing factor.

However, some amount of work is needed with research and UX so that the content structure improves the benefits that site visitors gain from the content.

SEO & SERP

People use Google to find stuff on the internet. The day when audiences came to a home page and then navigated through a site are long long gone (with Yahoo!). Now, Google surfaces an exact page a person wants, and that person quickly decides if the page is useful or not.

Search engine optimization (SEO) and search engine result pages (SERPs) are the way marketers use Google to reach audiences.

For some things, such as how-to guides, video and images will often be more useful than pure-text descriptions. Other topics may be text-heavy or pure-text (like this site).

SEO for each of these is critical for content to show up under the search terms audiences are most likely to use (which can also be defined and refined through focus group discussions, surveys, and more research options).

Audience Output: Content Types

With audience goals, search patterns, and expected media type in hand, the team can define content types.

Content types define the "unit of content" a visitor will consume. Examples: blog post, image gallery, image detail page, product landing page, product detail pages, video-focused pages, etc.

Usually, there will be several types at work. A mature site might have landing pages for ad campaigns, content marketing "posts" that address topics directly or tangentially related to the main products/services, how-to guides about the service/product, and FAQs where needed.

With these in hand, the team can then talk about the connections between each content type. For example, there may be a set of "universal" categories that can be used across all types. This category list can be maintained by the central structuring team, and it would be updated later as new categories emerge or SEO/UX/research determines ways the categories can be improved.

The main goal of the audience focused phase is a set of content types and universal categories/tags that are meaningful to an audience and that increase content value to the audience.

Note: "benefit" can be anything that causes the audience to feel their visit was good. It could be easier navigation between related blog articles, faster search for product categories, better page formatting on their phone, or anything else that is "good" in the eyes of the audience.

Summary: Content can only be as good as the authors writing it. The content models for each content type, and the software that lets author create and edit, must be part of the structuring process. Failure to include authors will result in authors finding ways to hack around clunky software, revert to editing in Word before copy-pasting, and similar sanity-saving activities.

Once content types are discovered and documented, these need to be converted into content models.

Starting with a very simple template definition

The easiest way to think of a content model is as a template for a type.

Blog posts may minimally have a title, body text, and a header image. The model is "title, body text, header" and then every blog post would include these.

Landing pages might have a hero image, logo fields w/ links to white papers, pricing matrix, and links to related pages. The landing page model would be "hero, logos, pricing, related pages" or similar.

Defining types more completely (blog post example)

Let's use the "blog post" from above that includes a title, body text, and a header image.

First, we need to define the title more clearly.

How long should the title be for a blog post? Is the title mandatory?

For body text, can we include images in the text? How much layout is needed? Do we need anything beyond anchor/link tags and headers (h1, h2, h3, etc)?

Are there constraints on image types? What about image size, quality, and dimensions? Are images required?

Addressing author needs in the model

So far, a model is relatively lifeless. It starts to give some definition to a content type (like a blog post) but it doesn't address the content lifecycle.

Content isn't touched once. Well, good website content isn't written and forgotten. Good content is created, monitored, improved, pruned, and eventually removed as audience needs evolve (and as competitors fight for the same audience).

Let's go back to the blog post as an example.

Authors need guardrails in the model to make it easier to create.

Example: If a blog post title is mandatory, can a post be published without it? If a person attempts to publish, what kind of feedback do they need?

For each part of the content model, authors should indicate what they need to make content creation easier. Alerts, tool-tips, on-screen messages, and more are all options.

Authors have workflow needs that help them focus and collaborate.

"Content isn't touched once", we said.

How do we indicate a blog post is a draft or published? If multiple authors work on an article, is that captured? If content should be reviewed on some schedule, how do editors know this?

The content model should include relevant workflow details or status lists that can help authors and editors write and maintain content as a team.

Authors need to describe the content as a part of the whole.

Content does not exist in a vacuum. Each post, image, or clip has a relationship to others.

Blog posts have categories or tags, and these are shared with other blog posts. The categories used for a blog post might also be shared with and used on product category pages, how-to videos, and more.

The content model also needs to record the categories, tags, taxonomies, and other content-focused details that help authors describe the content as a whole and that can allow for "related content" links, search/filter pages, and more.

Summary: Audiences have to read, see, and/or hear what authors have created. Developers make this happen by building systems that let authors store content, then deliver the content to audiences. Along the way, developers also have to think about a ton of technical matters and SEO-related matters that can influence the audience reaction.

When content types and related metadata have been defined as content models by the authors, developers convert this into schema. Schema are the technical files and tools that define the content in databases, help define editorial interfaces, and more.

Developers aren't the audience or the authors.

Developers are one-step removed from the audience and authors. Their specialty is HTML and databases and version control and stuff like that.

The more the developers understand about the audience or author, the better the results of their efforts.

Sure, developers can create the perfect content management system from a sketchy bunch of details and requirements.

Fair warning, "perfect software" usually means "useless" because developers fill in the blanks where the requirements aren't clear OR they over-engineer where the requirements are super-detailed.

So perfect software means a system with lots of vague fields or missing workflow steps, OR it's a system that's so detailed it's impossible to use.

Or, worst, it's both.

The schema creation is a dialogue

Unlike the first two steps, schema creation is a conversation between developers and authors, and indirectly with the audience.

This is because the developers don't have the same class of needs as audiences or authors. Audiences want benefits the content delivers. Authors want the ability to create and manage content.

Developers want to create software that people use.

What does this mean? Why is it in a section about "a dialogue"?

When a developer is creating HTML templates based on a content model and they hit a point where the model isn't complete, that developer needs to ask "what does the audience want?"

If the developer can't get an answer, they fill in the blank with what they (a human) feel is reasonable in that situation.

Often, this is OK. Sometimes, it's not.

Similarly, if authors ask for a specific workflow process and status hierarchy, developers can implement this but there are always cases where something that seems simple turns out to be messy. If developers can't get an answer from authors or authors insist that it's really simple (when it's not), developers will do their best.

Sometimes, this is OK. Often, it's not.

Authors aren't developers.

The corollary of "developers aren't the audience or authors" is that authors aren't developers.

Thus, as developers build a system from a content schema, they will need to ask questions and authors need to be engaged in this dialogue.

MOST IMPORTANTLY: this dialogue never ends as long as a site is being updated and there is an active audience. Audience evolution may introduce new content types. A growing author team may require changes to models or workflows or metadata.

Summary: Audiences want the best content. Authors want to create content. Developers want to deliver content. The last step for a structured content project defines ways to measure improvements in each of these areas.

You are likely working on existing content hosted on an established system. Change can be difficult, especially when a structured content project starts and surfaces gaps, problems, and opportunities.

Audience-focused changes

Hopefully, you already have a solid analytics setup to track audience behavior, engagement, and demographics. If not, you have a first goal: get analytics running on your site. Without analytics, you have no idea if your changes are meaningful to audiences.

But, assuming you have analytics running, the structured content team should discuss what SEO or SERP metrics are most important. If none of the pages on a site rank near the top of a page for a term? Focusing on structure that improves SERP placement might come first.

It's also possible there's a need for a complete overhaul. The site might be very out-of-date and needs a rebuild. In this case, it's useful to look for benchmarks that can be used as initial goals for a new site. Keyword research sites are often part of larger services that provide benchmarking and other data useful in this regard.

Author-focused changes

First: "articles written per week" or other "productivity" metrics are usually a bad idea. I'm stating this first because quality is almost always more important than quantity for SEO, audience metrics, and conversions.

Given this, the list of changes related to creating content should be prioritized by authors. Some might be minor, like updating a list of categories that is extremely outdated. Others can be major, such as removing annoying workflow steps that are no longer used or automating steps.

The main point is that authors should be polled for their "net promoter score" for a site in the same way as audiences for an entire site. If authors are happy with the systems to create and manage content?

That is a good thing.

The content model and metadata should help guide author priority, but debates about what's most important are great ways to find both goals to improve author experience AND to find new needs of the authors as they discuss the current model, software, and how they get work done.

Developer-focused changes

As developers introduce changes, notes should be made on any analytics that indicate the day of a change and what changed.

New taxonomy introduced and sitemaps submitted to Google? Note it.

Updated author workflow to automate steps and remove unneeded and distracting fields? Note it.

Then, watch the audience reaction. Sometimes it will be instant.

When Google introduced AMP, a site I helped got it working and traffic jumped 30% within a week. That's amazing.

More often, a change is made that seems innocuous and traffic drops because something broke, performance crashed, the sitemap broke, or something else cruddy snuck onto the site.

But, importantly, developers' role in this is very different than authors. You can't get traffic without content, so authors need to be able to produce new content. Developers can, unfortunately, undermine the best content with systems that are slow, crash, or mangle content.

So most developer metrics are guardrails that ensure changes do not negatively impact a site. But, where possible, it's also good to see where there's a correlation between developer changes and traffic changes.

Get it done.

What's next though? That's still a little cloudy?

If content types in an existing system are out of line with what audiences want, then a site needs to be restructured and things like "information architecture" and "content site maps" are probably in your near future.

If content models are out of sync, look for the differences that would be most meaningful to author happiness and productivity. Prioritize those for getting fixed.

And if the current content schema is far out of whack to the existing technical configuration? Work to see where high-value audience and author needs can be handled first, but be prepared to discuss if it's time to build a new site from the ground-up. Sometimes, a clean start is best even if it's the same CMS or service, just with a new, clean back-end and history.