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 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.).
A client had only 2 months to launch a new web site with 300 pages of content. Since the development was projected to consume at least 1 month, they knew they wouldn't have enough time to create content after the development work is done.
Therefore they decided to use Kentico Cloud to start content production in parallel with the development. This approach allowed them to finish the project on time.
A partner was migrating 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 Kentico data structures. They considered the Kentico import toolkit, but since some data had complex relationships, they decided it would be easier to build custom import tools.
A client had 6 months to launch a new web site. The partner estimated that the development phase would take 3 months. As content would not be ready until then anyway, the client decided to enter the content directly into the CMS in a staging environment.
A client wanted to use Kentico's built-in e-commerce functionality, but their products were managed in an external ERP system. Since product information needs to be stored in Kentico in order to use the built-in e-commerce features, they determined that they would synchronize Kentico with the ERP system on a nightly basis.
To accomplish this, the partner built a custom scheduled task, which synchronized only the minimum of data that was necessary to make the e-commerce features work. When displaying product information, they connected to the ERP live to get data not available in Kentico.
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.
- When using the portal engine:
- 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.
- 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 phone, cell phone > smart phone, and apple categories).
- Use field references when you need reference another object of a specific object type (e.g., assign a country (built-in object) to an office page).
- Consider linking a page when sharing whole pages.
- Consider how editors might be able to re-use existing page 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.
- Logon page
- 404 Page Not Found (critical for SEO)
- Robots.txt (critical for SEO)
- Sitemap (critical for SEO)
- 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.
- 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.
- Evaluate whether you should use SKUs with pages versus the standalone SKUs option of storing products (see the E-commerce customization model documentation for more details).
- 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.
- 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.
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.
- 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.
- Attachments follow the life cycle and restrictions of the page they are attached to.
- 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).
- 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).