Pages vs Custom Objects vs Blog Posts in SGEN
How to choose the right content type for every piece of content
SGEN gives you three primary ways to store and publish content: Pages, Custom Objects, and Blog Posts. They look similar on the surface — all three produce published URLs, all three have a title and a body — but they are designed for different content shapes and different publishing patterns. Choosing the wrong one does not break anything immediately, but it creates friction every time you try to list, filter, or update that content later.
This guide is a decision map. It explains what each content type is for, shows you a decision matrix you can apply to any new piece of content, and walks through three real examples from Acme Coffee Roasters to show how the decision plays out in practice. By the end, you will know which type to reach for whenever you sit down to add something new to your site.
The short version: Pages are for permanent, standalone destinations that live in your site's main navigation or information architecture. Blog Posts are for dated, reverse-chronological content that belongs in a feed. Custom Objects are for structured, repeatable content that you will query, list, or filter — think products, team members, case studies, or any content that has consistent fields across many records of the same type.
When you use the right content type, maintaining your site gets proportionally easier as the site grows. Team members added as Custom Object records appear on the team list page automatically. Blog posts about new product arrivals land in the feed in the right order with no layout work. Landing pages built as Pages live at clean URLs and can be added to navigation menus in one click. Each type does its job; none of them tries to do the others'.
What is this for?
This guide is for any SGEN admin who is starting to add content and is not sure which type to reach for. It is also useful for admins who have been using the wrong type for a while and want to understand whether a migration makes sense.
The confusion most often shows up in one of three situations: someone creates a blog post for something that should be a page (the contact page, the about page, a campaign landing page); someone creates a page for something that should be a Custom Object (each team member gets their own manually built page); or someone uses a Custom Object for something that should be a blog post (a company news item that has a date and should appear in a chronological feed).
All three are common. All three create cleanup work later. Use this guide proactively before you add a new content category to your site, and retroactively when something feels hard to maintain — adding a new team member requires manually building a new page from scratch, for example, which is a reliable signal that team members should be a Custom Object instead.
Decision matrix at a glance
The table below is the short version of this entire guide. Scan it first; the rest of the page explains the reasoning behind each row.
| Question | Page | Blog Post | Custom Object |
|---|---|---|---|
| Is this a permanent destination? | Yes | No | No |
| Does the publication date matter to visitors? | No | Yes | Sometimes |
| Will you create more than ten of these over time? | Rarely | Yes | Yes |
| Do they share a fixed structure (fields)? | No | Loosely | Yes — strict |
| Should they be auto-listed somewhere? | No | Yes (blog index) | Yes (your list page) |
| Do you want a category / tag taxonomy? | No | Yes | Optional |
| Do you want RSS or scheduled publishing? | No | Yes | No |
| URL pattern | /slug | /blog/slug | /<type>/slug |
| Belongs in main navigation? | Usually | The blog index, yes | The list page, yes |
| Cost to add another item | High (build from scratch) | Low (post editor) | Low (record form) |
Feature side-by-side
| Capability | Page | Blog Post | Custom Object |
|---|---|---|---|
| Drag-and-drop builder | Yes | Yes (lighter) | Per-field editor + a template |
| Custom fields | Add via Custom Codes | Tags + category | First-class — define once, fill per record |
| Search inside the type | Site-wide search | Blog search | Your list page's filter |
| Bulk operations | One at a time | Bulk publish / trash | Bulk import / export |
| Reverse-chronological list | No | Yes — built in | Configurable on your list page |
| Best ratio of build-effort to count | 1 to 1 | 1 build, many posts | 1 build, many records |
Good use cases
Use this section to map your own content to the right type. Every item in this list is a real scenario from Acme Coffee Roasters or one of its sister brands.
These are permanent destinations that belong in your main navigation and do not have a publication date that matters to visitors. Acme Coffee Roasters has an About page, a Wholesale page, and a Contact page. All three are Pages. They are updated periodically but never published in a feed.
What NOT to use this for
This comparison guide covers the three primary content types. It does not apply in the following situations.
Media goes in the Media area regardless of which content type it is attached to. This guide is about text-and-URL content types, not files.
How this connects to other features
The content type you choose affects which SGEN features you can use with that content.
— Pages can be added to your navigation menus directly by selecting them in the Menu Builder. Blog Posts and Custom Object records are typically linked via their full URL rather than selected from a picker. If you want a piece of content to be a permanent navigation item, a Page is the easiest type to work with.
Before you start
Before you create a new piece of content, answer these three questions in order. The answers will tell you which type to use.
Question 1: Does this content belong in a dated, reverse- chronological feed? If the date it was written matters to visitors — it is news, an announcement, an article, a guide with a publication date that readers reference — it is a Blog Post. Stop here.
Question 2: Will you have multiple records of this type with the same fields? If you will have five or more records of the same content shape — five team members, eight products, twelve testimonials — and you want to list or filter them together, it is a Custom Object. Stop here.
Question 3: Is this a permanent, standalone destination in your site's information architecture? If it is in your main navigation, your footer, or your sitemap as a fixed destination, it is a Page.
If none of those three questions produces a clear answer, default to a Page. Pages are the most flexible content type and the easiest to migrate content out of if you later realize a different type fits better.
Where to go
To create a Page: go to Pages in the left sidebar, click Add New.
To create a Blog Post: go to Blog in the left sidebar, click Add New Post.
To create a Custom Object record: go to Custom Objects in the left sidebar, select your object type, then click
Add New Record. If the object type does not exist yet, create the type definition first under Custom Objects then Type Settings.
Steps — Identify the right content type and create your content
These steps walk you through the decision process for any new piece of content and then through creating it in the correct content type.
1. Apply the three-question test before opening the dashboard
Write down what the new piece of content is in one sentence. "A profile of our head roaster Maria Santos" or "An announcement about our new subscription box" or "Our privacy policy page." Then apply the three questions from the Before you start section above.
For "profile of our head roaster": Does it belong in a dated feed? No. Will we have multiple records of the same type with the same fields? Yes — four roasters, same fields each. That is a Custom Object.
For "announcement about our new subscription box": Does it belong in a dated feed? Yes — it is news and the date it was posted matters. That is a Blog Post.
For "our privacy policy": Is this a permanent, standalone destination? Yes — it lives in the footer navigation and never expires. That is a Page.
If you apply the test and still land in ambiguity, default to a Page. It is the most flexible type and easiest to migrate content out of if you change your mind.
2. Create the type definition if using Custom Objects for the first time
If the three-question test lands on Custom Object and the object type does not yet exist in your dashboard, you need to create the type definition before creating records. Go to
Custom Objects in the left sidebar, then open Type Settings or Manage Types. Click Add Type.
Give the type a singular name: Team Member, Coffee Variety,
Client Story. Define the fields that every record of this type will have. For team members, that might be: Name (text), Title (text), Bio (rich text), Photo (image). Define all the fields you plan to use before adding records — it is easier to add fields to a new type than to retrofit them after you have twenty records.
Save the type definition. You will now see it as a selectable type in the Custom Objects area, and you can start adding records.
3. Create your content in the correct type
Go to the correct area and add your content using the standard editor for that type.
Pages: fill in the Title, write the content in the editor, set the URL slug, fill in SEO fields, and publish when ready.
Blog Posts: fill in the Title, write the body, select a Category, set the publish date, fill in SEO fields, and publish.
Custom Objects: fill in each defined field, upload any associated media, set the URL slug for the detail page, and save. Leave Status as Draft while writing. Flip to Published only when the content is complete and reviewed.
4. Verify the content appears in the expected location
After publishing, verify the content appears where it should. For a Page, visit the URL you set as the slug and confirm the page loads. For a Blog Post, visit your blog index page and confirm the post appears at the top of the feed. For a Custom Object record, visit the list page for that object type and confirm the record appears.
If a Blog Post is not appearing on the index page, check that it is Published (not Draft) and assigned to a category the index page displays. If a Custom Object record is not appearing on the list page, confirm the record is Published and the list page query includes the correct type.
5. Set SEO fields on every piece of content
Regardless of which content type you chose, open the SEO panel in the editor's right sidebar and set the SEO Title and Meta Description. These fields are often left blank when content is created quickly and they are the most direct lever on search visibility you have.
Blog Posts deserve particular attention here — they accumulate over time and each one is a separate document that search engines index. Every published post with a blank meta description is a missed opportunity to rank for that specific topic.
6. Build or update list pages that should show the new content
If you added a new Custom Object record, verify your list page is pulling it correctly. If the list page uses a dynamic query — pulling all published records of the type automatically — it updates on its own. If it uses a static layout, update it manually to include the new record.
For Blog Posts, the blog index handles itself — new published posts appear automatically in reverse chronological order. For Pages, add the new page to a navigation menu or link to it from other pages, since Pages are not auto-listed anywhere.
What success looks like
When you use the right content type, the experience of managing your site becomes proportionally easier as the site grows.
- Adding a new team member means opening Custom Objects, selecting Team Members, clicking Add New Record, and filling in the same four fields every team member has. The new member appears on the team list page automatically. Five minutes, consistent result.
- Publishing a new blog post means opening Blog, clicking Add New Post, writing, assigning a category, and publishing. The post appears at the top of the feed. No layout work.
- Adding a new landing page means opening Pages, clicking Add New, building the layout, and publishing. The page is accessible at its slug and can be added to navigation in one click.
- Your content inventory is easy to reason about. You know that team members are Custom Objects, articles are Blog Posts, and destinations are Pages. Nothing lives in the wrong place.
What to do if it does not work
There is no automatic migration between types in SGEN. Create a new record in the correct type, copy the content, and then trash or unpublish the old record. Set a redirect from the old URL to the new URL if the old page was published and receiving search traffic.
Example 1: Acme Coffee Roasters — building the team page
Acme has four roasters. When the fifth joins, Sarah realizes she has been building a new page from scratch for each person — copying layout, swapping in names and photos, updating links. She has four pages named Roaster-Maria, Roaster-James, Roaster- Kenji, and Roaster-Priya. Adding a fifth is the same forty- minute layout job.
She creates a Custom Object type called Team Member with five fields: Name, Title, Bio, Photo, and Start Year. She creates four records — one per roaster — and builds a Team page that queries all published Team Member records and renders them in a grid. Adding a fifth team member now takes five minutes. She trashes the four old roaster pages and sets redirects from each old URL to the new team page.
Example 2: Acme Coffee Roasters — weekly roastery updates
Acme posts a weekly update about what's on the roaster, what new arrivals came in, and what's selling out. Sarah initially created each update as a Page. Six months in, she has thirty Pages named "Update April 7" through "Update October 27" and no way to list them chronologically without manually updating a curated list page every week.
She creates a new Blog category called Roastery Updates, marks all thirty existing update Pages as "to migrate," and over two weeks moves each one into the Blog as a Post with the correct publication date. The blog feed now handles chronology and the category filter automatically. She trashes the thirty old update Pages.
Example 3: Acme Coffee Roasters — landing pages
Acme runs three Google Ads campaigns simultaneously: one for wholesale, one for subscription boxes, and one for their in-person workshops. Each campaign needs a dedicated landing page with a specific URL, custom headline, and embedded form.
Sarah creates three Pages — not blog posts, not custom objects. They are one-off destinations. They are not repeating records with consistent fields. They are not dated content for a feed. They are Pages. Each gets its own slug, its own SG-Builder layout, and its own lead-capture form. Campaign performance is tracked separately by form submission counts.