Back to posts
Loading article...
When I set up Sanity for Costa Rica Inspire, I started with the changes the agency would make after launch. They might add a tour, update a shuttle route, or change the phone number in the footer. Each of those edits needed a place in Studio where the team could find it again.
How the Studio is organized
Services contains separate lists for tours, hotels, destinations, and vacation packages. Each entry has its own document. Next.js can use those documents for the listing and detail pages, and the homepage can point to existing records for its featured sections. When the agency updates a featured tour, the homepage and tour page can read from the same record.
Transportation has its own section because a service, a pickup location, and a route are separate records. A route references a service and two location documents. Studio groups route lists by private transfer, shared shuttle, and lake crossing. Editors can choose an existing location when adding a route, and update its name in one place.
Website pages opens one fixed document for each route, including the homepage, service index pages, About, and Contact. That’s where the agency edits section headings, introductions, and other page-specific copy. For example, the Tours page document controls the introduction to the listing, while an individual tour document holds the details for that tour.
Site settings is a single document for business details, social links, footer text, and default SEO. I gave FAQs, testimonials, and service categories their own lists because editors can manage those records separately from the page that displays them.
How Next.js reads the content
The homepage headline is a quick way to see the setup. In Studio, go to Website pages, then Homepage, then Hero. Heading and Second heading line are two fields on the same homePage document. On the server, getPageContent("homePage") fetches that document and passes the hero fields to HomeHero. Both lines render in one heading.
The other pieces have their own fetchers. The service fetchers read lists and individual records by slug. The transportation fetcher reads services, locations, and routes. The settings fetcher reads the one Site settings document. The repository’s publish webhook checks the source and signature before invalidating the appropriate Next.js cache tag. Page copy uses a tag per page, and site settings and shared service content have their own tags.
Prompts for Codex or Claude Code
Paste these one at a time. Start with the audit so the agent can account for the routes, schemas, and content your site already has. Work through the parts your project needs, then use the last prompt to test them together.
1. Map the site and the editing tasks
Audit this Next.js repo and any existing CMS setup. List the public routes, the content editors need to update, where that content lives today, and every page that reuses it. Sort it into repeatable records, page-specific copy, and site-wide settings. Flag existing slugs, shared references, hardcoded values, and content that must carry over. Propose the schema types, Studio menu, and implementation order. If Sanity is missing, outline a local Studio and test dataset setup. Return the plan before changing files or data.2. Create the service collections
Using the approved content map, implement or extend Sanity document types for the services this site actually offers. For a travel site, review tours, hotels, destinations, vacation packages, and transportation. Give records stable slugs where they have detail pages. Add fields the existing listings and details use, including image alt text and validation. Use references for categories and related records. If transportation pricing varies by route, model services, reusable locations, and routes separately, with route references for the service, origin, and destination. Organize the lists in Studio. Prepare test records and an import plan for existing content that preserves slugs and relationships. Apply data changes only to the confirmed test dataset.3. Make page content editable
Add or reuse one fixed Sanity document for each existing route whose copy editors manage. Put these documents under Website pages in Studio and label sections as editors know them, such as Hero or Tours section. Model the actual headings, introductions, images, links, and SEO fields used by each page. Use references for featured services. Keep the current layout and URLs. Walk through how a homepage heading and a service index introduction would move from their current source into the schema, query, and rendering component.4. Set up site-wide settings
Audit shared values used by the footer, contact page, WhatsApp link, and metadata. Add or reuse one Site settings document with a fixed ID. Group business details, footer copy, and SEO defaults so editors can find them. Use existing approved values for the migration plan. Wire each public consumer to the same source and define how page-specific SEO overrides site defaults. Keep email delivery credentials and recipients managed by the server. Check what happens if a setting is empty or invalid.5. Connect Sanity to the Next.js routes
Connect the schemas to the existing Next.js routes using the project's installed version and data conventions. Reuse server-side Sanity clients and parameterized GROQ. Fetch the fields needed by each list, detail page, and shared component. Resolve references and keep types in sync. Check canonical URLs, unknown slugs, empty lists, and optional fields. Reuse the project's published content and cache strategy. Map each document type to the routes or cache tags it affects, and use a verified webhook if the current setup needs one. Keep secrets server-side and report any Studio or hosting setup that still needs to happen.6. Test the editor workflow before launch
Use a separate Sanity dataset and a local Next.js instance. Confirm the active dataset and content perspective. Test a service edit that appears in a listing and detail page, a featured service reference, a transportation route with two locations, a page heading change, and a site settings change in every relevant component. Confirm a draft stays off the published view, then publish to the test dataset and check how the changes reach the site. If something stays stale, inspect the document ID or slug, query, webhook delivery, and affected cache tags. Run the project's relevant checks and report what passed, what you could not verify, and any remaining import or deployment steps.Read the original case study for the hosting costs and why I chose this stack.