Planning content management

Create a strategy for the initial and ongoing content and asset production, organization, etc.

Content Production

Content is created and managed inside Kentico Xperience

If content is managed this way, the developers must prepare the data structures and storage before content can be entered. If the project is already live, we recommend using a staging environment for content creation rather than directly editing in the production environment.

Content is created and managed outside of Kentico Xperience

This content is typically used for items like a product catalog and is either synchronized to Kentico using custom-built scheduled tasks, e.g., using Hangfire or Quartz.NET, or pulled directly from the external system at runtime (e.g., web services, SDKs, etc.).

Content migrated to Kentico

A partner was migrating to a client's web site from an existing CMS. Since the CMS had most of the content stored in a structured fashion, they decided to import the content using the Kentico API. 
 
As they completed the data structures for each type of content, they created a simple one-time import tool to map the content from the old CMS to the Xperience data structures.  

Content tree or sitemap

Content organization, URLs and SEO

  • The organization of the content tree can be used to generate the structure of the XML sitemap for search engines. Xperience does not generate the sitemap automatically, you need to build the feature yourself, for example, using the SimpleMvcSitemap library.

Content taxonomy

  • Use organization of pages in the content tree to create your website’s taxonomy. As a result, your page will always belong to only one category.
  • If you need advanced taxonomy setup, e.g., using tagging, we recommend building a custom module that provides both the editors UI to assign their content to specific categories, and a way to store and then retrieve the references in code.

Sharing content

  • Define which content needs to be presented across multiple places on the same website or in different channel (upcoming feature)
    • Consider storing this information in structured content types in the Content hub so that editors can reuse the content effectively

Securing content

  • Restrict access to content items based on visitor authentication.
    • Visitors can register on an Xperience website to become members. When they sign into the system, they can browse pages or access member-only sections of the website.

System pages

  • Decide which of the following system pages need to be in the tree and editable by content editors.
    • Search result page
    • Logon page
    • 404 Page Not Found (critical for SEO)
    • Robots.txt (critical for SEO)
    • Sitemap (critical for SEO)
  • We recommend providing Page builder functionality for Search result, Log on, and 404 pages so that editors can personalize their content to improve customer experience.

Content life-cycle

  • Define a content life cycle and list all necessary steps.
  • Consider the following to keep outdated content under control:
    • Hide pages from live site by archiving or unpublishing them.
    • Move pages to a dedicated archive location in the content tree.
  • Identify how often content should be reviewed.
  • Control data growth and keep desired performance by having processes in place to:
    • Delete old pages (with replacement URL redirection for SEO purposes).
    • Move old pages out of the content tree (e.g., to a custom module class).

Performance

  • Keep the total pages for all sites, including culture variants, under 500K pages.
  • Keep the number of direct children of any particular page under 1K.
    • Keep content categorized, grouped, or structured using some rule (e.g., group content by release date: /Blogs/2016/January/My-Blog-Post).
  • Move content outside of the content tree after publishing if you expect there will be too much content.
    • This allows you to use workflows while keeping the content tree size small.

UI personalization

  • Restrict access to applications, functionality, or modules users don't need to work with.
    • Restrict editor access to certain actions, e.g., sending email within the Emails application, as necessary.
    • Restrict editor access to certain buttons by customizing the Rich text configuration(e.g., source view, font color, etc) as necessary.

Media Organization

Determine the proper way to store media files on the website by analyzing the nature of the files (e.g., sizes, types, quantity), as well as how they will be used (e.g., do they need security, resizing, or watermarking).

Depending on your requirements, we recommend storing most files in the in the Content hub using a custom content type. Your content type will allow editors to upload binary files and create content item assets.

Content Hub

  • Content hub is a preferred way for storing your assets.
  • Store your media assets using a custom content type, e.g., Media. Define content properties per business requirements, e.g., Media description, Alternative text, Media title, etc.
  • For referencing your custom media content type from other content types and in widget properties, use the Content item selector for your Form Component.

Media Libraries

  • Use when storing many files or large files, especially when you need bulk-uploading.
  • Avoid media libraries if you need to secure the files, as the files are always accessible (Note: you can restrict access to a media library in the administration interface, but the files are still public).

Design assets

  • Xperience by Kentico follows Microsoft conventions for ASP.NET 6 Core applications.
  • Store static files in the default directory ({content root}/wwwroot) with dedicated subfolders for your assets.
    • Xperience bundles Page and Form builder resources (scripts and styles) by default in the {content root}/wwwroot/Content/Bundles folder. You can identify thesee files from their system prefix. Find out more about default bundling behavior and how you can customize it in the documentation.
  • Follow .NET conventions and store your static files used for website design, such as images, favicons, fonts, JavaScript, and CSS files in subfolders within the wwwroot.