Static Content? Inconceivable!
Static pages. Dynamic content. Clean URLs. Databases. Templates. Flat Files. Publishing systems.
We’ve created a puzzling environment for putting content on the web, and the way different technology vendors use the same words with different meanings attached can make learning a new system a nightmare for anyone, much less someone new to the whole deal.
In a recent forum post a newcomer to ExpressionEngine posted:
I’ve been confused about “static” pages and “dynamic” pages so the post above this makes no sense to me. I like to use wordpress for any blogs that I do and I’ve always been told to make whatever page I want to show up better in the search engines a “static” page. Is a “static” page in wordpress the same as a “dynamic” page?
I responded in that thread, but also wanted to post the response here on Train-ee because understanding ExpressionEngine’s approach to “static content” is fundamental to understanding how the system works, or can work.
I Do Not Think That Word Means What You Think It Means
Static content is confusing because there are three mindsets driving the terminology: content management,database/backend/implementation, and search engines.
From a Content Management Perspective:
This perspective looks at the nature of the content rather than the implementation.
However there is content that changes often. Blog index pages change whenever you post something new. Product content changes with new releases. Staff profile pages change when someone leaves or someone new hires on. Because the content changes more often it’s “dynamic”.
From a Database / Backend / Implementation Perspective:
This perspective looks at the nature of how the content is stored on the server rather than the nature of the content itself - ie is the content stored in a database or in a text file?
Static pages are those where when you navigate to http://mydomain.com/about/the_company.htm there is a /about/ directory on the server with a text file named the_company.htm that contains HTML, CSS, and content. It’s “static” because the file gets created and sits on the server.
With EE everything past /index.php/ in the URL doesn’t necessarily exist on the server at the file level. When that URL is requested EE goes to its template library and creates the web page on the fly using instructions found there. The result only exists in the users browser - so it’s “dynamically-generated” page. Things get a little fuzzy here because EE allows developers to store their templates either as flat-files on the server or in the EE database - but either way those templates are not visible to end users, only the pages created by the templates.
From a Search Engine Perspective:
This perspective (at least as it relates to the topic at hand) is mainly concerned with URL formations. Dynamic content has historically had ugly URLs - like something from Amazon:
Search engines had a harder time indexing this content, and even when it was indexed it wasn’t ranked as highly due to the ugliness of the URL (and because some of those numbers were user ids or session ids that didn’t apply to everyone navigating to that page).
What the search engine wanted instead was something like:
Not only is the URL more “readable” by humans, the search engine can more safely assume this is a good indexable page, not likely to change, not containing use or session-specific content, and of good general interest to their users.
Soooo…What’s “Static” Mean in ExpressionEngine?
From a content management perspective content can either be static or dynamic. EE handles any sort of content well, from never-changing About pages to constantly-changing Blogs. From a database/backend/implementation perspective pages are (usually) all dynamic. From a search engine perspective it’s the best of both worlds - dynamically generated with with clean URL structures.
As an EE developer it’s up to you how you want to handle the implementation of content that’s less likely to ever change:
- You could hard-code all static content into flat-file templates and save EE from having to constantly perform database queries to retreive the same unchanged content every time it’s requested. While this would be more efficient from a system perspective, it means if that content ever does change the person changing it needs access to that template. I’ve never been willing to do that for most clients, and don’t want to be on the hook for changing content on their behalf (the entire reason I got into EE to begin with). If you store your EE templates in the database then your content is stored there as well and technically not truly “static”.
- You could put your “static” content in channels and create dedicated templates & template groups to present it the same way as other dynamic content. Yes, this means the system does more work with having to query the database for content that rarely changes, but now that content is always available for clients to edit through EE’s edit interface. You can use some of EE’s caching abilities to mitigate the database work required here. There are a number of tutorials here on Train-ee showing this approach.
- You could use ExpressionEngine’s Pages Module. Don’t be mislead - this Module is not required to create “static pages” in ExpressionEngine, but can offer some benefits for the right project. Essentially once the module is installed and configured you can work outside of EE’s normal URL structures and assign your own URL to a page. You can also create a common template to route all of these pages through. Downsides to using this module are loss of the use of segment variables (since you are essentially masking a custom URL over EE’s normal URL) and having to reveal your templates to your content editors (concerning to me because there is usually one right choice and many wrong choices).
- You could look to third-party options like Structure or Taxonomy to work with static content in a more advanced way.
So don’t let the terminology fool you - with ExpressionEngine you have several tools available (both native and 3rd party) to handle any sort of content in a way that’s highly efficient & effective for the end client, you as the developer, and for search engines.
Just a bit of cliff-climbing required to figure it all out…