Site Migration — Content Architecture

A news article in Webflow is a visual layout. A news article in a structured content system is data: it has a title, a publish date, a body, a category, an author, and an image — each as a separate, typed field. That same article can render on a website, appear in an email newsletter, respond to an API query, or be read by an AI assistant. The content is written once and used everywhere.

I defined 12 document types and 3 reusable object types in Sanity CMS that model SCA's operations. The document types are the main content — pages, news, programs. The object types (SEO metadata, social links, announcements) are reusable structures embedded inside multiple document types for consistency. Full schema details are in the Appendix.

These types have relationships — a Program can reference its Coach (a Person), a Person belongs to a Department, Pages have parent/child hierarchies. This is what makes the data queryable in ways that flat pages can't be.

Four architectural decisions shaped this work. These reflect SCA's institutional needs — how they're best implemented in WordPress is where platform expertise comes in.

1. Sanity for the content layer. Sanity provides a real-time API, typed schemas defined in code, and a content studio that editors can use without developer help. The content is accessible via HTTP — any system that can make a GET request can read it.
2. Astro for a reference frontend. I built a deliberately minimal reference website to prove the content layer works. It renders all the structured data into real pages, but the visual design is intentionally secondary — because the architecture keeps data and presentation completely independent. Any frontend can consume the same content with a different design.
3. Content extraction before rebuilding. Rather than manually recreating content, I programmatically extracted everything from the Webflow site — page text, program descriptions, news articles, images — and imported it into Sanity as structured data. This work doesn't need to be repeated.
4. AI-readable by design. The site outputs static HTML with JSON-LD structured data and semantic markup. No JavaScript is required to read any page. Any LLM with web access — ChatGPT, search engine crawlers, prospective parent AI assistants — can parse the content directly. The public API means AI agents can also query school data programmatically.

Use this as a scope reference. Green = equivalent or better. Yellow = partially built (data model exists, frontend incomplete). Red = not started. New capabilities not on the current site are marked separately.

The 12 content types translate directly to WordPress Custom Post Types with Advanced Custom Fields (or equivalent). Each type has defined fields and relationships:

• Programs with category, level, description, coach reference, college placement data → CPT with ACF fields + relationship to Person
• People with roles, bios, department references → CPT with taxonomy or relationship field
• Pages with parent/child hierarchy, rich text, SEO fields → native WordPress pages with custom fields
• News, Events, Student Projects, Alumni Stories → each a CPT with typed fields rather than freeform page builder content

Full schema details with every field and relationship are in the Appendix. This can serve as a starting point for CPT registration and field group setup — optimization suggestions from WordPress implementation experience are welcome.

• All text content extracted programmatically from Webflow — page text, program descriptions, news articles — stored as structured data. Can be imported into WordPress or consumed via API.
• 87 images downloaded and hosted on Sanity's CDN. Available for re-import into WordPress media library.
• WordPress can implement this model directly (CPT + fields), integrate with the existing content API, or take a hybrid approach — recommendations on what works best are welcome.

• Google Drive automation. Student project system provisions Drive folders when a project is created. Independent of the website frontend.
• Editorial workflow. Source tracking (manual, Instagram, external) and QA flags for imported content.
• New content types (alumni stories, media galleries, boarding features, admissions paths) have schemas defined but no content yet.

• Contact forms — Standard WordPress form implementation needed.
• Gradelink integration — URL field exists in site settings; enrollment button to be wired into frontend.
• Faculty data migration — Requires manual import or custom parsing solution for Webflow's photo grid format. Schema is ready to receive data.
• Image relationship mapping — Assets extracted and hosted; linking to specific content entries to be completed during WordPress migration.
• Community/engagement pages — Backend schemas complete; frontend implementation pending design decisions.

Whether we begin with Foundation Phase or Infrastructure Phase, the goal is architecture that can evolve. Foundation Phase (professional web presence) is a viable starting point provided it can migrate to Infrastructure Phase (structured content) without rebuilding from scratch. The specific risk to manage is not page builders themselves, but content locked into proprietary shortcodes or layout-specific blobs that cannot be cleanly extracted later. I'm not attached to any particular WordPress pattern — what matters is that content remains portable.

Build Custom Post Types + custom fields that replicate the 12 content types. Content is imported into WordPress directly. Sanity serves as the reference for what the content model looks like; WordPress owns everything going forward.

• Standard WordPress architecture: CPT + ACF (or equivalent) + templates
• Content imported from Sanity export or re-entered manually
• Schema design, field definitions, and relationships documented and ready
• All frontend work (themes, forms, plugins, SEO) lives in WordPress

This represents the Infrastructure Phase path. The content model defines what "program" and "person" and "event" mean for SCA, so the WordPress build starts with a clear data architecture instead of a blank slate. If starting with Foundation Phase using conventional themes, the architecture should keep content in standard WordPress structures (posts, pages, native fields) rather than embedding it in page builder shortcodes or proprietary block formats — so that migrating to CPTs later is a data operation, not a content re-creation effort. A question for discussion: are there scenarios where consuming the Sanity API directly makes sense for WordPress, or is native CPT implementation the better path for SCA's needs? Input on this is welcome.

Areas where professional input would be valuable:

• WordPress architecture recommendations given these content relationships
• Approaches to balancing editorial usability with structural integrity
• WordPress best practices for content exportability
• If starting with Foundation Phase: which theme architectures best support future migration to CPTs? If starting with Infrastructure Phase: recommended CPT architecture for these content types
• Standard approaches for custom fields: ACF, blocks, or other options
• Performance/SEO baselines: Core Web Vitals, images, caching

Angelene's vision for SCA's AI-forward positioning can be realized through progressive stages, depending on implementation scope and timeline:

Foundation Phase focuses on professional web presence with visual polish, mobile responsiveness, and basic content management. Content is presented through established WordPress themes. This phase may utilize page builder tools for rapid deployment, with the understanding that content will be migrated to structured CPTs in Infrastructure Phase. The goal is bridgeable architecture, not permanent page-builder dependency. This delivers immediate institutional value and positions SCA for future enhancement.

Infrastructure Phase implements the full structured content model described in this document — CPTs with defined fields, queryable relationships between content types, API accessibility, and AI-ready architecture. This enables automated content workflows, multi-channel publishing, and the complete AI-forward capabilities that differentiate SCA's positioning.

Both phases serve SCA's journey. The question is whether to implement the complete infrastructure now, or to establish the foundation first and evolve to full structure in a subsequent phase.

The following describes SCA's Infrastructure Phase destination — the complete structured content architecture. Not all of these are Phase 1 requirements. Foundation Phase may utilize interim solutions (conventional themes, manual curation) as a viable starting point, with the understanding that these evolve toward the target architecture over time. The destination includes:

• Content stored as structured data. CPTs with defined fields. A "program" has a name, category, coach, and description as separate queryable fields.
• Relationships between content types are queryable. A program references its coach (a person). A person belongs to a department. Pages have parent/child hierarchies. These connections must be navigable in code.
• Content is exportable and portable. If SCA changes platforms in the future, all content and relationships can be extracted cleanly.
• AI-readable output. Static HTML with semantic markup and structured data (JSON-LD). No JavaScript required to parse content. This is how prospective families' AI assistants, search engines, and SCA's own AI tools will interact with the site.

I'm not presuming to dictate WordPress implementation details — that's the domain of platform expertise:

• Theme architecture, plugin stack, hosting environment
• Custom fields approach — ACF, native blocks, or another pattern
• Editorial workflow and content management UX
• Performance optimization, caching strategy, deployment pipeline

To ensure we meet SCA's institutional needs, these are the outcomes I'd like us to align on. Implementation choices will determine how these are achieved in WordPress:

• Faculty, programs, news, and events are template-driven from structured data — not manually assembled pages
• Content relationships are preserved (program → coach, person → department, page hierarchy)
• The site renders semantic HTML that AI tools and search engines can parse without executing JavaScript
• Content can be exported to JSON or another portable format at any time

The structured content architecture described in this document has value beyond the immediate website migration. Once content is stored as typed, relational data:

• AI tools can query institutional content directly — answering parent questions, generating marketing materials, supporting admissions workflows
• Content can be published across multiple channels (website, mobile app, printed materials, social media) from a single source
• Institutional knowledge is preserved as queryable data rather than locked in page layouts
• Future platform migrations become data transfers rather than content re-creation

These capabilities become available regardless of when Infrastructure Phase is implemented. The architecture is the prerequisite; timing is an organizational decision.

I provide content architecture, business requirements, and AI-readiness strategy. Implementation expertise guides WordPress-specific decisions. If Foundation Phase is the starting point, I can identify which decisions now will ease the transition to Infrastructure Phase later. My priority is ensuring we don't close doors to Angelene's full vision.

Each document type is a structured content definition with typed fields and relationships. You can query any of these via the public API (see Try the API below).

These are reusable structures embedded inside document types — not standalone content. They ensure consistency across the system.

What's actually in the system right now (live data, queryable via API):

The content API is public for reads. You can paste these URLs into any browser to see live data. No setup, no tokens, no plugins.

This is standard HTTP. WordPress can consume these endpoints with wp_remote_get(). Any language with HTTP support works.

The reference frontend uses design tokens — named values for colors, typography, and spacing — rather than ad-hoc styles. This is a starting vocabulary, not a complete design system. The value is the approach: tokens can be mapped to any CSS framework, WordPress theme, or design tool, and AI tools can iterate on them systematically. Changing the visual design doesn't require changing the content.

To see all of this in action: visit the reference site. The design system is implemented as CSS custom properties (design tokens) — any developer can inspect them in the browser's DevTools.

For developers familiar with WordPress, here's how the Sanity concepts translate: