Development of IP.Content 2.3 continues, and as mentioned in the introductory "What To Expect" blog entry, one area of the software we wanted to place a focus on was search engine optimization. While this particular subject can bring about heated debates regarding what is "good" and what is "bad", there are a few areas of IP.Content that we felt could use some specific improvements. Today we're going to discuss a few of the SEO improvements you can expect to see in IP.Content 2.3.
Header Codes
There is no denying that sending the appropriate header response code based on the results of a page request is important. If the page loads normally, as typically happens while browsing around a website, a 200 response code is returned to the browser (and spiders) to let it know everything is ok. When the page cannot load correctly for some reason, a more appropriate response code is required. If the content cannot be found, this response code should be 404, and if you do not have permission to view the content it should be 403. As Matt reported in the IP.Board 3.3 Dev Update: SEO Improvements, other non-specific errors will now return a 401 header code. This is the default that IP.Board uses, so if a more specific response code is not specified, an error page automatically issues this 401 response code now.
We have taken the time to go through all IP.Content actions to update the response codes that are returned. Previously, no response code was specified, so all error pages would return the default (previously a 500, though this has changed with IP.Board 3.3, as mentioned). Now, pages that are "not found" will return a 404 response, and pages you do not have permission to access will return a 403 response code. Pages, by the way, also include database categories, articles, and other database-specific views that can be delivered (such as a request to add a new article).
Meta Tag Configuration
While this change really relates to improving the usability of the product more than SEO, we'll include it here since the change we are discussing relates to configuring your database meta tags. In IP.Content 2.2, each database (including the articles database) allows you to configure meta tags for that database specifically. The problem here is that you can also configure them at the page level (e.g. you can specify the meta tags for each individual page in the Page Manager area). So, once you embed a database into the page, which meta tags should be used? The ones you configured for that page, or the ones you configured for the database? When viewing categories and articles (or other database records), there are specific meta tags available for these areas as well, although they are still relevant and there is still value in customizing these separately.
The decision has been made to remove per-database meta tags, and instead utilize the meta tags you configure for the page itself, in an effort to clarify the interface and remove duplicate configurations that have proven to be unnecessary and confusing.
Page Titles
One of the more relevant and controllable areas of search engine optimization is your page titles. IP.Content utilizes your "Page Name" as the page title (the text inserted into the <title></title> tags of the page), which works well in most scenarios. When you embed a database into a page, however, IP.Content 2.2 uses the database name as the page title. When navigating further down into the database, the category name or article/record name is instead used as the page title.
Customers have requested a change in this behavior and better control of this experience, and we are happy to announce there will be several changes coming in IP.Content 2.3 to allow you better control of your page titles across the software.
Beginning with IP.Content 2.3, the default page title format for databases will be as follows:
- Index page: Database name - Page name - Website name (or board name, if no website name)
- Category page: Category name - Database name - Page name - Website name (or board name, if no website name)
- Record page: Record name - Category name (if available) - Database name - Page name - Website name (or board name, if no website name)
We have not stopped there, however. We have separated the function that handles this out so that it is now possible to write hooks to override this functionality, allowing developers to come up with other ways to enhance or modify the page title formatting. And, additionally, we have also built in a custom formatting system that power users who require further control or refinement, or simply believe a different format works better for page titles, can now utilize for complete control. If you wish to change the format of the page title beyond the default, you can now do so by adding 3 constants to your conf_global.php file, and within these constants you can use macros to create different page title formats. While more information will be posted in our documentation section on this closer to release, here is the general code to give you an idea:
* define( 'CCS_PAGE_TITLE_CAT', '' ); * define( 'CCS_PAGE_TITLE_RECORD', '' ); * // Following variables will be replaced: * // {page_name} = Page name * // {database_name} = Databae name * // {category_name} = Category name (only available for CCS_PAGE_TITLE_CAT and CCS_PAGE_TITLE_RECORD) * // {record_name} = Record name (only available for CCS_PAGE_TITLE_RECORD) * // {website_name} = Website name as configured in ACP * // {board_name} = Board name as configured in ACP
* define( 'CCS_PAGE_TITLE_HOME', '' );
You could thus specify "(Website Name): Record Name - Category Name" for records, or you could have "Record Name - Page Name (And some custom text here)". Ultimately, if you wish to redefine your page titles, you can now do so with relative ease, and without having to worry about future updates reverting your tweaks.
But wait, there's more! We didn't want to make a few minor changes to the format of the page title and call it a day. Many users have explained that while they want to name a page something simple (i.e. "News"), because that name is used in many places across the software, they may want their page title to say something different (i.e. "News - everything you need to know about my website subject matter"). How can we accommodate this as well?
We have added a new option to the page form that allows you to optionally specify a page title that is different from the page name. To be clear - the page name will continue to be used throughout IP.Content, while the page title you specify will ONLY be used in the <title></title> tags, allowing you to completely control it. It should be noted, as well, that this new field is optional, so you aren't required to fill in the same name twice for all of your pages, or edit each of your pages upon upgrade to give it a separate title.
When you uncheck the box, you can now specify a separate page title
We have implemented this same new functionality for categories as well, so you can now define a category page title separate from the category name, should you wish to do so.
In the process of making these changes, we noticed that the breadcrumbs within databases would use the page name on the database home page, however once you navigated within the database, the database name was used in the breadcrumbs instead. We have changed the breadcrumb navigation to always use the page name, and not the database name, to improve consistency and maintain hierarchy definition of the site.
Redirecting Duplicate Page Requests
While working through the system we found that page requests that are different, but load the same page, do not redirect to the correct form of the URL. For instance, if I have IP.Content at "www.site.com" and my default index page is "index.html" (and I have not enabled the option to remove the page name from the URL for this page), then I can access the same page via the URL "www.site.com" or via "www.site.com/index.html". The same page is loaded from two different URLs. As a general rule for SEO, this is bad, and all URLs that point to a page should redirect to the correct form of the URL for that page. We have enhanced IP.Content to detect this scenario and it will now 301 redirect these duplicate requests to the correct form of the URL.
Pages Tab
The "Pages" tab in IP.Board, if you have not hidden it, links to "index.php?app=ccs" by default. The system is designed to load your default page (with a fresh install, this would be "index.html" in the root of your Page Manager), and while we have already implemented a feature to redirect duplicate URLs to the correct form of the URL as described above, we took this one step further for the Pages tab. A new hook will be included with IP.Content 2.3 that rewrites the "index.php?app=ccs" URL used for the Pages tab by default so that it links to the correct form of the URL for your default page. This will reduce the number of duplicate URL requests that have to be redirected and help ensure only one URL is used to refer to any one given page (especially your index page, likely the most important and trafficked page of your IP.Content installation).
Memory System
IP.Content gives you a lot of flexibility and control, allowing you to fully define the URLs of your pages. You can define the full folder and page name structure for your pages; you can define the FURL string to use for your database categories; you can even define static FURL strings for your articles and other database records. This allows you to remove any ids from all of your URLs, but the tradeoff is that if you ever change your mind and rename a page, or a category FURL string, or an article FURL string, the system has no way to know where an old URL should point.
For example, say you gave a database category a FURL string of "information". Your URL to this category is "site.com/articles/_/information/". A year down the road, you want to change this information page to an FAQ, and you want to update the FURL string to reflect this. The URL to this category becomes "site.com/articles/_/faq/". After a year, search engine spiders have surely indexed the previous URL, and visitors may click it in a search engine listing to reach your site. The problem is, that old URL no longer exists, and because it was a static piece of information without an ID, IP.Content has no way of knowing where the request should be pointed to now.
We have eliminated this problem with a URL memory system, automatically available for pages, categories and records/articles with a static FURL string (if you do not explicitly define a static FURL string for articles a dynamic one is used with an ID, so this problem does not exist in this scenario).
If you rename a category/page/article in IP.Content 2.3, it will remember the old URL behind the scenes. If a request is received and cannot be processed, IP.Content checks it's memory system to determine if the URL previously was valid, and if so, where it pointed to. IP.Content will then 301 redirect the request to the new URL, eliminating problems with broken links when you change your pages after they have been indexed. This was a highly requested feature, and we hope it makes managing your URLs easier, and more forgiving when you change your mind later on.
Wrap Up
We are continuously monitoring feedback we receive from clients, and we understand that SEO is important to you. We wanted to take the time to implement useful functionality changes in the software that will help your site grow. At the same time, we want to focus on proven areas that have a real measurable effect, and that will benefit all of our customers. We believe the changes discussed in this blog entry will improve both the user experience, as well as the experience search engine spiders have while indexing your website. It should be noted, as well, that every single one of these ideas stemmed from feedback suggestions in our IP.Content feedback forum, where we encourage you to share your thoughts with us! We welcome your comments on these changes below!