Configure your CMS

When you're clear on your CMS requirements, you can also be clear on how you'll need to use it, to make it work for you.

Think of your CMS like a service. Its users are the writers, designers, developers and other staff people who use it to manage content. When choosing or developing a CMS, involve the writers and designers who will use your CMS to help you choose or develop it. This will help you get a clear idea of what you need it to do.

Needs of a CMS:

• workflow and roles
• navigation tree management
• ability to create, edit, approve, publish and unpublish content
• ability to manage files within the system
• access to support and training

Start with the specific needs of people who will be using the system. How well will your CMS meet their needs? Focus on the needs of the people using the CMS, rather than extra features you may not use.

A CMS helps content teams to work together. You can set up various user roles for your web team in your CMS.

Each of these roles will have a different purpose and access level. Sometimes these roles may be the responsibility of one or more people.

For example, an editor may not be able to publish content. This helps quality control and supports workflow.

Typical CMS roles:

• Author — sometimes called a content creator or writer. This includes preparing and writing content in the CMS
• Editor — edits existing content
• Approver — has the final say on whether to publish a piece of content
• Publisher — pushes content to the ‘production’ site

List who is responsible for each part of the content. Specify what they'll need to do and what access they'll need in the CMS.

Workflow refers to how you manage content in a CMS throughout the content lifecycle.

Aim to keep your workflow simple: write, edit, approve and publish may be enough. If you need multiple levels of checks and approvals, you may want a more detailed workflow.

Document what clearances are needed to publish content to help you manage and track workflow.

You may be able to connect the CMS to agency staff directories. This allows you to send notifications for approvals and preview links before publishing.

You need good workflow to use a CMS effectively. Make a list of the people who will be using your CMS and what the overall workflow is.

Talk with your developer when setting up your CMS to support thect workflow.

• How easy is it to set up workflow and follow it in your CMS?
• Does the CMS supports the workflows your agency requires?
• Do you need to supplement the CMS workflow with your own separate system?
• Can users easily log in from other locations?
• What does each person need to do with the content?
• How many active CMS users you can have at a time?

There are several terms and labels (CMS taxonomy) to become familiar with when using a CMS. Some common terms include:

• content pages — standard pages that you will create and add content to in the CMS
• page id — the unique identification reference number automatically assigned by the CMS to each page on your site
• landing pages — the website pages that users will land on from search engines or a link
• assets: images, downloads, attachments etc that you use on different pages of your site
• metadata — page titles, descriptions, SEO tags and labels used to describe different types of content
• categories and topics — the way you structure content in your CMS so that users can easily navigate your site and find information

When CMS taxonomy is used correctly, both your SEO and your information architecture will also be improved. This will create a better user experience.

CMS taxonomy and SEO

When content is consistently and accurately tagged in your CMS, the right content can appear in search results, helping to connect users with the right information.

CMS taxonomy and IA

Content in your CMS should be structured based on your content types and your information architecture. Use your content categories and topics to clearly label and structure content clearly in your CMS. Refer also to taxonomy in the IA guidance for more on this.

Find out how long it takes to make a change on your site. For example, a CMS that can't make quick changes may be a problem. This may have a lot to do with your security requirements and deployment methods.

For example, find out how long it takes from when a content change is made or a security patch is applied in the CMS, until it is deployed or seen on the front end.

Make a list of editors who need to log into the CMS to make quick changes. If you need to schedule times when you can make changes, plan ahead for this.

Configure the CMS to manage the different types of content you'll be creating. Define sets of default content fields, so they can be applied to different types of content.

The information entered into your content type fields will affect how your CMS displays content on the front end.

Make a list of the content types you need your CMS to manage.

A CMS should help you manage content in a consistent way. Use 'help text' to describe what each field is for. This helps authors meet strategic, format and style needs.

Templates and content types used in your CMS will help guide writers by explaining what copy goes in different fields and sections in your CMS.

Help text can contain:

• target audience
• style guidance
• example copy
• number of characters

Use specific and descriptive names for content type fields. Use simple field names to explain which content goes where (for example, event name, event description, main event photo and event booking details)

Adding useful 'help text' is a simple thing you can do to support people to publish better. Speak with your developer about optimising 'help text' in your CMS. Always display it in a clear way to make it easy to read and understand.

WYSIWYG stands for 'what you see is what you get'. This is the default kind of content editor for a CMS. It is sometimes also called a rich text editor. You should configure your WYSIWYG text editor to follow your own agency’s style guide.

The CMS text editor should instruct writers about style and format. Some examples include fonts, colours, sizes, heading styles and metadata.

You may also refer to the Style Manual for more on this.

Editing features should support content writing. Limit the editor to basic styles and features of the style guide. Too many options makes it easy to create content that doesn’t follow the style guide.

The editor should support accessible images. You will also need to specify the image formats and file specifications that the CMS will accept.

Talk to your developer to find out how reliable and secure the text editor is, and if you need to use HTML.

Some areas to be aware:

• Potential need for customisation of content using HTML
• Type of code used (ie; open source versus proprietary systems)
• Suitability for everyone who needs to use it
• Compliance with accessibility issues
• Regularity of CMS updates and new versions
• Reliability and compatibility with current technologies and changes

A headless CMS provides a consistent framework for content editors to create and manage content for multiple platforms. It has no front end (or ‘head’) like a traditional CMS, and no traditional ‘view’ functionality.

A traditional CMS manages a single website. A headless CMS is an option if you want to manage content in one place, but send it out to different platforms. These can include platforms such as mobile apps, custom web pages, widgets etc. This works by using software called an API, which sends out content from the CMS to the different platforms.

Keeping content in one place makes it easy for content editors to manage content on different sites. A CMS may be able to act as a hub, publishing content to many different sites. A consistent tagging system will also define where content will appear on your site/s.

For example, news content can benefit from this approach. A single news item can appear on several related websites by publishing one page in your CMS.

Some CMSs provide basic site statistics. Compare this against external analytics platforms and your reporting requirements.

If you need deeper analytics, check if the CMS can integrate into an external analytics platform. This may be an added cost.

Find out if there’s an easily available and reliable support community to help you optimise your CMS and fix issues quickly.

A good support community can make weeks of difference in getting the help or development work you need. An active community may also be more likely to help with bugs and issues. This is more common in an open source CMS.

CMS customisation is all about continual improvement.

There are 2 kinds of customisation:

• functional customisation — changing the way the CMS works
• cosmetic customisation — changing the way the CMS looks

Different CMSs have different levels of custom default behaviour. Some are flexible, others are more restrictive. Knowing what you need from your CMS helps you to know if it has enough built-in support. If you need to make changes, you may need to hire specialist developers. This can be expensive and time consuming.

For continual CMS improvement (upgrades, fixes, support), also consider who you'll need to do this, so that you're not caught out with CMS issues later.

Migrating content means moving content from one platform (CMS or website) to another. The decision to migrate content is a big decision. It is all about careful and safe content management. It also raises questions about the value of content. Content migration needs to be carefully considered before making a decision to go ahead.

If you do decide to migrate content, take the time to create a clear exit plan, assess risks, and put a clear and thorough process in place. Always refer to your content strategy along the way, so that your actions are in alignment with it.

Badly implemented content migration can result in poor site performance, reduced SEO and poor-quality traffic. It can also impact on the user experience.

There are several questions to ask before you start and to engage all CMS stakeholders in the process:

Answer each of these questions thoroughly.

• Why are you migrating content?
• What content do you need to move or remove?
• What is the process for moving content?
• How will data be preserved when you move it across?
• Will your SEO be affected?
• Who is responsible for the migration of content?
• What content backups will be made before and after the move?
• How will you know if your content has been successfully migrated and/or stored?
• Who will set up content in the new CMS?

Please refer to our guidance on how to manage the content. This also covers how to conduct a content audit, migrate content safely and how to conduct a risk analysis.

If you are closing down your website altogether, please refer to our guidance on how to decommission a website.