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 Your Store 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.

Feature side-by-side

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 Your Store or one of its sister brands.

• Use a Page for: About, Contact, Wholesale, FAQs, Pricing.

These are permanent destinations that belong in your main navigation and do not have a publication date that matters to visitors. Your Store 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.

• **Use a Blog Post for: Store updates, announcements,

event news, seasonal product launches, founder letters.** Your Store posts a weekly store update — "This week's new arrivals" or "We just added a new Canvas Tote Bag." These have dates, live in a feed, and accumulate over time. Blog Posts are the right type for any content where the date a piece was published matters to the reader.

• **Use a Custom Object for: Team members, product catalog,

wholesale partners, press mentions, testimonials.** Your Store has fourteen products in their catalog. Each has the same fields: name, price, description, availability. A Custom Object type called Products with those four fields means adding a new product is adding a new record — not building a new page from scratch.

• Use a Page for: Landing pages from ad campaigns.

A dedicated landing page for a Google Ads campaign is a Page. It does not belong in the blog feed. It does not repeat across many records of the same type. It is a one-off destination with its own slug and lives as long as the campaign runs.

• Use a Custom Object for: Case studies or client stories.

Your Store Wholesale has six case studies — each one a client story with the same structure: client name, challenge, result, quote. A Custom Object type called Client Stories means filtering and listing six stories by industry is possible. Individually built pages cannot be queried that way.

• Use a Blog Post for: How-to articles and product guides.

Your Store publishes how-to guides — how to style a Canvas Tote Bag, how to care for a Classic T-Shirt. These are dated, accumulate over time, and belong in the blog feed. A how-to guide from 2024 lives alongside a store update from 2026 because both are Blog Posts and the blog handles chronology automatically.

• Use a Page for: Legal pages, cookie policy, privacy policy.

These are permanent, rarely updated pages that live in the footer navigation. They are not news items and they are not structured repeating records. They are Pages.

What NOT to use this for

This comparison guide covers the three primary content types. It does not apply in the following situations.

• **Do not use this guide to decide where to put uploaded

files or images.** 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.

• Do not use a Custom Object when you only have one record.

If you have one featured case study and no plan to add more, a Page is the right place for it. Custom Objects earn their complexity when you have multiple records of the same type that you want to query or list together.

• **Do not create a Blog Post for content with no meaningful

publication date.** If the date a piece was written does not matter to a visitor — your About page, your product pricing, your store hours — it is not a Blog Post. The blog feed is ordered by date and evergreen content buried in it becomes invisible over time.

• **Do not use a Page for content that changes frequently

and needs to be listed or queried.** If you add a new team member every month and want a page that lists them all, one page per team member is the wrong structure. Custom Objects with a list page is the right structure.

• Do not mix types within the same content category.

If your team members live in both Pages and Custom Objects, you will not be able to build a single list that pulls all of them. Pick one type per category and be consistent.

How this connects to other features

The content type you choose affects which SGEN features you can use with that content.

• Navigation / Menu Builder — 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.

• Blog index and categories — Blog Posts are automatically

included in your blog feed and can be assigned to categories. Pages and Custom Objects are not. If you want content to appear on a paginated, filterable blog index page, it must be a Blog Post.

• Custom Object list pages — Custom Objects can be queried

and displayed on list pages using SGEN's template system. You build the list page once, and every Custom Object record of that type is automatically available to query. Pages and Blog Posts cannot be queried this way.

• SEO fields — All three content types have SEO Title,

Meta Description, and Canonical URL fields. The choice of content type does not limit your SEO capability — all three can be fully optimized.

• SG-Builder — Pages have full SG-Builder support for

visual layout. Custom Object detail pages and Blog Post templates may have more limited builder support depending on your SGEN version and template setup.

• Forms — Forms can be embedded on all three content types.

The content type does not restrict your ability to embed a contact form, lead form, or survey on a given piece of content.

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 lead designer" or "An announcement about our new product line" or "Our privacy policy page." Then apply the three questions from the Before you start section above.

For "profile of our lead designer": Does it belong in a dated feed? No. Will we have multiple records of the same type with the same fields? Yes — four team members, same fields each. That is a Custom Object.

For "announcement about our new product line": 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, Product, 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

• You chose the wrong content type and want to move content.

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.

• Your blog index is not showing a new post.

Check that the post is Published (not Draft). Check that it is assigned to a category the index page displays. If the index page filters by category and the post is in a different category, either reassign the post or update the index page's filter settings.

• A Custom Object record is not appearing on the list page.

Confirm the record is Published. Confirm the list page query is set to the correct object type. If the list page was built with a static layout, update it manually to include the record.

• **You have team member pages as Pages and want to convert

them to Custom Objects.** Create the Custom Object type definition first. Add each team member as a record. Build a list page that queries them. Set redirects from each old page URL to the new Custom Object detail URL. Then trash the old Pages.

• A Page is appearing in the blog feed.

Pages do not appear in the blog feed — if you see unexpected content in the feed, it is in fact a Blog Post that someone created instead of a Page. Check the content type of the unexpected item.

• You cannot find the Custom Object option in your sidebar.

Custom Objects may not be enabled on your current plan or may require an admin to set up. Contact your SGEN account owner or support team to confirm Custom Objects are available for your site.

Example 1: Your Store — building the team page

Your Store has four team members. When the fifth joins, the team realizes they have been building a new page from scratch for each person — copying layout, swapping in names and photos, updating links. There are four pages named Member-A, Member-B, Member-C, and Member-D. 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 team member — 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 team member pages and sets redirects from each old URL to the new team page.

Example 2: Your Store — weekly store updates

Your Store posts a weekly update about what's newly in stock, what new arrivals came in, and what's selling out. The team initially created each update as a Page. Six months in, there are 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 Store 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: Your Store — landing pages

Your Store runs three Google Ads campaigns simultaneously: one for wholesale, one for a seasonal sale, and one for their in-person events. Each campaign needs a dedicated landing page with a specific URL, custom headline, and embedded form.

Three Pages are created — 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.