2. 3. Planning content management

Every organization has a different process for managing content. Some projects have strict legal requirements whereas others may have a minimal set of suggested guidelines for editors. You need to understand and plan for these requirements up front. By supporting the business processes of the client, you are setting them up for continued success. In this section we explore the key facets to creating a solid content management strategy. 

Content production

Content is created and managed inside Kentico CMS/EMS

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.

Content is created outside and managed inside of Kentico CMS/EMS

When content is managed in this fashion, the content can be created before or parallel to the development. One example of such a system is Kentico Cloud, which enables content editors to create content in advance before the site is ready for them, while enabling developers to easily import this content to Kentico EMS via Kentico Cloud API.

Another example would be if all content was created in spreadsheets or in some other system with data structures that can be mapped and imported using the Kentico API or via the import toolkit.

Content is created and managed outside of Kentico CMS/EMS

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

Content not available. Content not available. Content not available. Content not available.

Content tree or sitemap

Content organization, URLs and SEO

  • This is also used to generate the structure of the XML sitemap for search engines.
  • Modify the URL of page or add aliases only as needed.
  • Utilize wildcard URLs to use a single template for displaying dynamic content from various sources (e.g., custom tables, custom module classes) while still having SEO friendly URLs.

Content taxonomy

  • Organize pages in the content tree if you only need simple categorization, where a page belongs to only one category.
    • Use page relationships when you need to manually create relationship between different pages (e.g., related news stories).
    • Use tags when you need a flat, non-hierarchical structure that allows for classifying pages based on various criteria (e.g., topics).
    • Use categories when you need to have a hierarchical structure to page classification (e.g., an iPhone page could be assigned with the cell phonecell phone > smart phone, and apple categories).
    • Use field references when you need to cover a very specific scenario to reference another object of a specific object type (e.g., assign a country (built-in object) to an office page).
    • Use advanced content modeling when you need to enable editors to build more complex content using other content (primarily used for MVC development model).

Sharing content

  • Consider linked pages when sharing whole pages.
  • Consider using viewer web parts or the API when sharing only the content of a page (e.g., home page slider content or the latest 5 news items).

Securing content

  • Grant permissions per user or role (memberships can be assigned with roles and gain permissions indirectly this way).
  • Check permissions only when necessary as it is performance intensive.

System pages

  • Logon page
  • 404 Page Not Found (critical for SEO)
  • Robots.txt (critical for SEO)
  • Sitemap (critical for SEO)

Content life-cycle

  • Apply different Kentico workflows to different sections or pages if necessary.
  • Specify authorized roles or users to modify, approve, or reject the page in each step as well as to be notified about these changes.
  • Consider restricting the number of page versions in the settings since all content under workflow is automatically versioned.
  • Consider enabling the content locking feature in order to prevent unintended overwriting of content changes.
    • 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.
    • Delete old pages (with replacement URL redirection for SEO purposes).
    • Move old pages out of the content tree (e.g., to a custom table or custom module class).
  • Consider automating content processing with advanced workflow.

Multilingual content

  • Use translation services to automate the translation process (this can be part of an advanced workflow).
  • Use culture specific URLs (e.g. /en-us/news and /fr-fr/news) for the same page to meet your SEO requirements.
  • Consider whether a page should fall back to the default content, 404, or other page if it is not available in the current language.

Products (SKUs)

Performance

  • Keep the total pages for all sites, including culture variants, under 500K pages.
  • Keep content categorized, grouped, or structured using some rule (e.g., group content by release date: /Blogs/2016/January/My-Blog-Post).
  • This allows you to use workflows while keeping the content tree size small.

UI personalization

  • Restrict editor access to certain page properties (e.g., metadata, URL alias, etc.) within the Pages application as necessary.
  • Restrict editor access to certain buttons (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).

We recommend storing most files in the standard media library which stores the files on the disk by default. Furthermore, this approach also provides the easiest path to using a CDN. We recommend avoiding serving files from attachments or the content tree unless you need functionality that can only be provided this way. 

Page files

  • Use the CMS.File page type for storing files in the content tree when you need features like workflow, multilingual support, search, permissioning, and categorization (tags or categories).
  • Avoid using the content tree if you plan to upload a large quantity of files or large size files as this can severely impact the performance.

Page attachments

  • Attachments follow the life cycle and restrictions of the page they are attached to.

Media libraries

  • Use when you are storing a large number of files or storing large files.
  • Use when you need to serve the files from a CDN.
  • Create a custom smart search indexer if you need to search in a media library, as the binary data of media library files is not searchable by default.
  • 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

  • Store your design assets on the file system in an organized way (e.g., images for a stylesheet should be stored in the App_Themes subfolder for the stylesheet they are related to).
  • Store JavaScript files in the Scripts/Custom folder to enable access to them from the administration interface.