<p>I start a technical SEO audit by building an inventory of public routes and their publication sources. Without that map, a crawl can find symptoms while missing the code or CMS rule that creates them. I compare static routes, generated pages, CMS records, sitemap entries, and redirects.</p><p>A one-day audit produces evidence and priorities. Search performance and field data may require follow-up because they come from external systems and longer time windows.</p>

<h2>Inventory routes and sources</h2>

<p>I collect routes from the application, CMS, sitemap, navigation, and known inbound paths. Each route gets a page type, source, expected status, canonical rule, and intended index state.</p><p>I normalize case, trailing slashes, parameters, and tag names before comparing sets. Duplicate-looking URLs often begin as inconsistent normalization.</p>

<h2>Check crawl and index controls</h2>

<p>I request robots.txt, sitemap files, representative pages, and redirects. I inspect HTTP status, X-Robots-Tag, meta robots, canonical, and sitemap membership together. Those signals should describe one policy.</p><p>I separate authored routes from platform noise and protected paths. Blocking a crawler is different from removing an already indexed URL.</p>

<h2>Inspect rendered metadata</h2>

<p>For each page type I check one title, description, canonical, Open Graph fields, Twitter fields, H1, and semantic heading order. Dynamic pages receive samples for missing and unusually long values.</p><p>I compare server HTML with the rendered page when JavaScript or CMS hydration can change content. A CMS field existing does not prove it reached the head.</p>

<h2>Validate structured data</h2>

<p>I parse JSON-LD, check supported types, and compare names, descriptions, URLs, dates, authors, and FAQs with visible content. Generated identity facts should override stale CMS copies.</p><p>Schema warnings become prioritized by user and search impact. Adding more schema types is not a substitute for correcting the page.</p>

<h2>Review links and performance risks</h2>

<p>I find broken internal links, orphaned routes, redirect chains, and navigation that points at noncanonical URLs. I sample server response time and Core Web Vitals evidence without claiming one lab run represents field performance.</p><p>Slow routes receive a measured follow-up for cache, backend, or rendering traces. The audit records the hypothesis and missing evidence.</p>

<h2>Turn findings into work</h2>

<p>I group findings by root cause and create tasks with affected templates, evidence, desired behavior, and validation. One shared metadata bug becomes one implementation card, not fifty page cards.</p><ul><li>Route sources are mapped.</li><li>Crawl signals agree.</li><li>Metadata and headings render correctly.</li><li>Schema matches visible content.</li><li>Priorities name one next action.</li></ul>

<h2>Need help putting this into practice?</h2>

<p>Terry Hunt Dev provides <a href="/services/technical-seo">technical SEO services</a> for sites with crawl, rendering, schema, or performance problems. Request an evidence-based audit through the <a href="/contact">contact page</a>.</p>

Follow my technical SEO audit process for inventorying routes, checking crawl and index rules, validating metadata and schema, and prioritizing fixes.

Technical SEO Audit Process: A One-Day Checklist

Follow a technical SEO audit through route inventory, crawl controls, rendered metadata, structured data, internal links, and prioritized fixes.

A Day Spent Auditing Technical SEO

<p>I give editors useful SEO controls without asking them to hand-author every technical tag. The content record stores a focused title, description, canonical choice, robots directive, and social copy. The frontend generates stable defaults and structured data from verified fields.</p><p>Strapi's component model lets an SEO field group repeat across content types. I keep JSON-LD support bounded because arbitrary schema pasted into a JSON field can contradict the visible page.</p>

<h2>Separate editable fields from generated facts</h2>

<p>Editors can write a meta title and description, choose indexability, and review social text. The application generates the canonical origin, publication dates, author identity, and route from current records. Those facts should not drift because someone copied an old schema block.</p><p>Fallbacks are explicit. A missing meta title may use the page title, while a missing canonical uses the normalized route. A malformed override blocks publication instead of producing silent head markup.</p>

<h2>Keep the SEO component small</h2>

<p>My reusable component contains title, description, focus keyword, supporting keywords, robots choice, social title, social description, and optional image relation. I add validation for lengths and allowed robots values.</p><p>I do not treat character counts as ranking rules. The limits protect interface quality and catch accidental paragraphs or truncated phrases.</p>

<h2>Generate schema from record facts</h2>

<p>A BlogPosting uses the current article title, canonical, author, category, and dates. A Service uses the visible offer and provider. FAQPage appears only when the page renders the matching questions and answers.</p><p>I merge a small allowlist of supplemental schema fields rather than letting CMS JSON replace generated identity, dates, or canonical values. That preserves flexibility without trusting stale facts.</p>

<h2>Validate canonical and robots together</h2>

<p>An indexable record should resolve to one HTTP 200 canonical URL. A draft record remains <code>noindex,follow</code>; a protected preview route may use stricter directives such as <code>noindex,nofollow,noarchive</code>. Both stay out of the sitemap. I reject conflicting states such as an indexable page canonicalized to a draft route.</p><p>Tags and location pages need the same rule. The CMS, rendered head, robots response, and sitemap should agree about whether the page belongs in search.</p>

<h2>Preview the rendered result</h2>

<p>I inspect the page source and rendered DOM for one title, one canonical, one robots directive, social fields, and valid JSON-LD. I compare schema text with the visible page and follow internal links.</p><p>Preview access remains protected and noindexed. A polished CMS form does not prove the frontend mapped the fields correctly.</p>

<h2>Add publication gates</h2>

<p>The publishing checklist catches missing descriptions, duplicate canonicals, unsupported schema types, hidden FAQs, and absent image alt text. Automated checks handle deterministic rules; an editor approves claims and page usefulness.</p><ul><li>Use safe metadata fallbacks.</li><li>Generate identity facts in code.</li><li>Allowlist supplemental schema.</li><li>Align robots and sitemap state.</li><li>Test the rendered page.</li></ul>

<h2>Need help with Strapi?</h2>

<p>Terry Hunt Dev combines <a href="/services/strapi-development">Strapi development</a> with <a href="/services/technical-seo">technical SEO</a>. Request a CMS metadata and schema review through the <a href="/contact">contact page</a>.</p>

Build Strapi SEO and structured data fields with safe fallbacks, canonical and robots validation, visible FAQ pairing, and publication checks.

Building SEO and Structured Data Fields in Strapi

Model titles, descriptions, canonicals, robots directives, social metadata, and supported JSON-LD in Strapi.

<p>I treat a content migration as a data project with a visible acceptance report. The source may be an older CMS, spreadsheet, database export, or files. Each source has missing values and conventions that should not become permanent Strapi fields without review.</p><p>I import into drafts first. Editors can compare records and rendered previews before anything becomes public.</p>

<h2>Inventory the source</h2>

<p>I count records by type and collect field names, formats, relations, media references, publication state, and URLs. I mark fields that contain HTML, embedded shortcodes, or mixed meanings. A sample of unusual records matters more than one perfect row.</p><p>The inventory includes current redirects and indexed URLs. A content move that preserves text but loses canonical paths can damage search and inbound links.</p>

<h2>Create a written field map</h2>

<p>Each source field maps to a Strapi field, transformation, default, or deliberate discard. I distinguish empty from unknown and record who approves defaults. Relations use stable source identifiers rather than titles that may repeat.</p><p>I create components only after finding a repeated structure. Parsing arbitrary HTML into a rigid component without enough evidence creates manual repair work.</p>

<h2>Normalize before import</h2>

<p>I normalize whitespace, dates, slugs, booleans, enum values, and URLs in a staging dataset. Duplicate slugs and malformed dates stop the run. I preserve the original source ID in a migration-only field or mapping file for reconciliation.</p><p>Media filenames receive safe names and alt text remains separate from captions. Missing alt text enters an editorial queue instead of being invented.</p>

<h2>Import drafts in dependency order</h2>

<p>I create independent records before records that reference them: authors and categories, then articles, then relation links. Media uploads happen through the configured provider and their returned identifiers feed the content import.</p><p>The importer is idempotent. Re-running a batch updates the mapped draft or skips it rather than creating duplicates.</p>

<h2>Compare data and rendered pages</h2>

<p>I compare source and destination counts, required-field failures, relation counts, missing media, duplicate slugs, metadata, and internal links. Then I render representative pages in Next.js and inspect headings, tables, code blocks, canonical tags, and schema.</p><p>Automated counts find broad gaps. Editorial sampling finds damaged meaning and poor formatting.</p>

<h2>Publish in a controlled batch</h2>

<p>I back up Strapi, publish a small approved batch, apply redirects, and crawl the public routes. The report records HTTP status, canonical, robots state, and missing links before the next batch proceeds.</p><ul><li>Source counts are recorded.</li><li>Every field has a mapping.</li><li>Imports are idempotent.</li><li>Drafts receive editorial review.</li><li>Redirects and rendered pages are tested.</li></ul>

<h2>Need help with Strapi?</h2>

<p>Terry Hunt Dev handles CMS architecture and migrations through <a href="/services/strapi-development">Strapi development</a> and <a href="/services/technical-seo">technical SEO</a>. Request a migration assessment through the <a href="/contact">contact page</a> with a field list, not private records.</p>

Use this Strapi content migration checklist to map fields, normalize slugs, import drafts, connect media and relations, and verify counts and rendered pages.

My Checklist for Migrating Content into Strapi

Inventory, normalize, import, and verify content in Strapi without losing relations, media, redirects, or metadata.

<p>A small-business website can keep loading for months while important work piles up behind it. The contact form may stop delivering messages. A plugin can fall several releases behind. Analytics can lose its consent settings after a theme change. None of those problems announce themselves on the homepage.</p>

<p>A useful website maintenance plan pays for someone to find those problems, fix routine issues, and explain when the site needs more than routine care. The monthly number depends on the website's technology, traffic, integrations, and the response time the business expects. A five-page brochure site and a membership application should not carry the same maintenance budget.</p>

<h2>What website maintenance costs pay for</h2>

<p>Hosting is only one line in the budget. Maintenance covers the human work and supporting services that keep the site dependable after launch.</p>

<table>
  <thead><tr><th>Cost area</th><th>Work included</th><th>Reason it belongs in the plan</th></tr></thead>
  <tbody>
    <tr><td>Hosting and infrastructure</td><td>Compute, storage, bandwidth, DNS, certificates, and email delivery services</td><td>The site needs a stable place to run, but usage and architecture affect the bill.</td></tr>
    <tr><td>Software and licenses</td><td>CMS, themes, plugins, form tools, monitoring, and other paid services</td><td>Renewals can interrupt features when nobody owns them.</td></tr>
    <tr><td>Updates and testing</td><td>Framework, dependency, CMS, plugin, and theme updates followed by functional checks</td><td>An update is incomplete until someone checks the pages and workflows it could affect.</td></tr>
    <tr><td>Backups and recovery</td><td>Scheduled backups, retention, restore access, and periodic restore tests</td><td>A backup that has never been restored is an assumption, not a recovery plan.</td></tr>
    <tr><td>Monitoring</td><td>Availability, errors, certificate expiration, form delivery, and performance checks</td><td>Monitoring shortens the gap between a failure and a response.</td></tr>
    <tr><td>Content and SEO care</td><td>Content edits, redirect upkeep, broken-link review, metadata, sitemap, and Search Console checks</td><td>Business details and search requirements change after launch.</td></tr>
    <tr><td>Support</td><td>Questions, small fixes, incident response, and coordination with vendors</td><td>The response time and included hours determine how much support capacity is reserved.</td></tr>
  </tbody>
</table>

<p>WordPress illustrates why updates and backups must be budgeted together. WordPress recommends keeping themes and plugins current and having a recoverable backup before updates because an update can cause problems. Its <a href="https://wordpress.org/documentation/article/plugins-themes-auto-updates/">auto-update documentation</a> also notes that scheduled updates depend on WordPress Cron and may not work on every setup. Other stacks use different tools, but the operating principle is the same: install changes in a controlled way and verify the result.</p>

<h2>A planning range is more useful than a universal price</h2>

<p>Published maintenance prices often look precise because the provider has already chosen the assumptions. A plan limited to thirty minutes of content edits is not comparable to one that includes monitoring, staging tests, and same-day incident response.</p>

<p>For early budgeting, build a scenario from the work instead of treating a market average as a quote:</p>

<ul>
  <li>A stable brochure site may need one or two scheduled review hours per month, plus hosting and licenses.</li>
  <li>A WordPress marketing site with several commercial plugins may need more update testing, license management, and rollback preparation.</li>
  <li>An application with logins, payments, APIs, or customer data needs monitoring, dependency review, recovery testing, and a defined incident process.</li>
</ul>

<p>Multiply the expected labor by the provider's rate, add third-party costs, and decide how much response capacity must be reserved. That gives the business a defensible planning figure. It also exposes the tradeoff: a lower monthly commitment usually means fewer checks, slower response, or more work billed outside the plan.</p>

<h2>Website maintenance checklist</h2>

<h3>Every week</h3>
<ul>
  <li>Confirm that the homepage, important landing pages, and contact path load.</li>
  <li>Review uptime and application-error alerts.</li>
  <li>Check that form submissions or other lead events reached their destination.</li>
  <li>Apply urgent security fixes through the site's normal test and deployment process.</li>
</ul>

<h3>Every month</h3>
<ul>
  <li>Review available CMS, plugin, framework, and dependency updates.</li>
  <li>Back up the database and files, then confirm the retention policy is working.</li>
  <li>Test navigation, search, forms, account access, and payment flows that apply to the site.</li>
  <li>Check Search Console for indexing problems and Analytics for unexpected tracking gaps.</li>
  <li>Review broken links, redirects, expiring content, staff details, and service information.</li>
  <li>Look at mobile pages and key performance measurements after material changes.</li>
</ul>

<h3>Every quarter</h3>
<ul>
  <li>Perform a restore test in a safe environment.</li>
  <li>Audit administrator accounts and remove access that is no longer needed.</li>
  <li>Review hosting usage, renewals, domain ownership, and certificate configuration.</li>
  <li>Test keyboard navigation, form labels, contrast, and other accessibility basics.</li>
  <li>Compare the website's main calls to action with the business's current priorities.</li>
</ul>

<h3>Once a year</h3>
<ul>
  <li>Review the complete technology inventory and replace abandoned dependencies.</li>
  <li>Confirm the domain, DNS, hosting, source code, analytics, and vendor accounts belong to the right organization.</li>
  <li>Revisit privacy notices, retention rules, consent settings, and form fields with qualified advisers where needed.</li>
  <li>Plan larger accessibility, content, performance, and technical SEO improvements.</li>
</ul>

<h2>Questions to ask before buying a maintenance plan</h2>

<p>Ask for the work boundary in writing. The answers make two proposals easier to compare.</p>

<ol>
  <li>Which hosting, license, and third-party charges are included?</li>
  <li>How often are backups created, where are they stored, and who tests restoration?</li>
  <li>Are updates tested on staging before production?</li>
  <li>Which pages and workflows receive routine functional testing?</li>
  <li>How are contact-form failures and uptime incidents detected?</li>
  <li>How many support hours are included, and what happens when they run out?</li>
  <li>What response time applies to an outage compared with a content edit?</li>
  <li>Who owns the accounts, source code, and documentation if the relationship ends?</li>
</ol>

<h2>Maintenance work that should become a separate project</h2>

<p>A recurring plan should handle predictable care. A redesign, CMS migration, new customer portal, checkout replacement, or accessibility remediation program needs its own scope. Keeping project work separate protects the maintenance time needed for updates and incident response.</p>

<p>The same applies when a neglected site enters maintenance with years of updates waiting. Start with a technical assessment and stabilization project. Once the site has a known baseline, monthly care becomes easier to price and deliver.</p>

<h2>Choosing the right level of care</h2>

<p>Match the plan to the cost of failure. A site that only publishes office hours can tolerate a different response time than a site that receives client inquiries or processes donations. Write down the important workflows, decide how soon someone must notice a failure, and fund the checks needed to meet that expectation.</p>

<p>Terry Hunt Dev offers <a href="/services/website-maintenance">website maintenance services</a> for organizations that want clear ownership of updates, monitoring, technical SEO, and ongoing support. If you need help defining the right scope, <a href="/contact">request a website maintenance consultation</a> and include the site URL, technology, current provider, and the problems you want the plan to prevent.</p>

Understand website maintenance costs, compare monthly plan options, and use a practical checklist covering backups, updates, SEO, and support.

Website Maintenance Cost & Checklist for Small Business

Plan a realistic website maintenance budget and see what responsible monthly support should include.

Website Maintenance Costs and Checklist for Small Businesses

Website Maintenance Costs: A Practical Checklist for Small Businesses

A practical cost framework and maintenance checklist for business websites.

Website Maintenance Costs for Small Businesses

<p>Law firm website content has two jobs before it ever reaches a search engine. It must help a visitor understand whether the firm handles the problem, and it must give that person a clear, appropriate way to make contact. Vague practice pages and oversized intake forms make both jobs harder.</p>

<p>This checklist covers content planning and technical implementation. It is not legal advice. The firm and its qualified advisers must approve statements about services, results, jurisdictions, credentials, confidentiality, advertising rules, privacy, and required disclaimers.</p>

<h2>Start with the visitor's decision</h2>

<p>A person arriving from search may know the legal issue but not the name of the practice area. Organize navigation and page language around recognizable needs, then explain the legal category in plain terms. Each page should tell the visitor:</p>

<ul>
  <li>which matters the firm considers;</li>
  <li>where the firm practices and any important limits;</li>
  <li>who at the firm handles the work;</li>
  <li>what information is useful for an initial contact;</li>
  <li>how to call or submit an inquiry; and</li>
  <li>what the visitor should expect after contacting the office.</li>
</ul>

<p>Avoid claims that outrun the firm's evidence or professional-responsibility review. The American Bar Association's <a href="https://www.americanbar.org/groups/professional_responsibility/publications/model_rules_of_professional_conduct/rule_7_1_communication_concerning_a_lawyer_s_services/">Model Rule 7.1</a> addresses false or misleading communications about a lawyer's services. State rules control and may differ, so the website review must use the rules that apply to the firm.</p>

<h2>Practice-area page checklist</h2>

<ul>
  <li>Name the matter in language prospective clients use.</li>
  <li>Explain the types of situations the page covers without promising an outcome.</li>
  <li>Identify jurisdiction or geographic limits when they affect whether the firm can help.</li>
  <li>Describe the general engagement process without presenting a universal timeline.</li>
  <li>Link to the attorney or team responsible for that work.</li>
  <li>Use a specific contact action, such as "Request an initial consultation," if that matches the firm's process.</li>
  <li>Add a last-reviewed date and a named content owner inside the firm's editorial records.</li>
</ul>

<p>One thorough page for a real practice area is stronger than a set of thin pages that swap city or service names. Location pages need facts that matter to the reader, such as office or service information the firm can verify. They should not imply an office where none exists.</p>

<h2>Attorney biography checklist</h2>

<p>Attorney biographies often receive high-intent visits. Treat them as working pages rather than ceremonial resumes.</p>

<ul>
  <li>Use the attorney's current name, title, photo, and contact path.</li>
  <li>List admissions and jurisdictions in the form the firm approves.</li>
  <li>Verify education, credentials, memberships, languages, awards, and dates.</li>
  <li>Describe areas of work with links to the relevant practice pages.</li>
  <li>Explain the person's role in terms a prospective client can understand.</li>
  <li>Remove departed attorneys promptly and redirect old biography URLs when a suitable destination exists.</li>
</ul>

<p>The website team should not infer expertise, certification, or representative results from incomplete source material. Ask the attorney or designated reviewer to approve the final biography and record that approval.</p>

<h2>Design the intake path around the first conversation</h2>

<p>A website form is usually an inquiry channel, not a full case-management interview. Request enough information to route and respond to the inquiry. Detailed facts and sensitive documents can move through an approved process after the firm decides how to proceed.</p>

<table>
  <thead><tr><th>Field</th><th>Planning question</th></tr></thead>
  <tbody>
    <tr><td>Name and contact method</td><td>Which fields are required to respond, and can the person state a safe contact preference?</td></tr>
    <tr><td>General matter type</td><td>Can a short controlled list route the inquiry without asking for a legal conclusion?</td></tr>
    <tr><td>Location</td><td>What minimum location information is needed for jurisdiction or routing?</td></tr>
    <tr><td>Opposing or related parties</td><td>Should conflict information use a separate approved workflow rather than an ordinary email?</td></tr>
    <tr><td>Free-text message</td><td>What guidance and length limit will reduce unnecessary sensitive details?</td></tr>
    <tr><td>File upload</td><td>Is upload necessary at first contact, and where will the file be scanned, stored, and deleted?</td></tr>
  </tbody>
</table>

<p>Place the firm's approved notice near the submit button where a visitor can read it before sending information. The firm decides the language about confidentiality, attorney-client relationships, deadlines, and emergencies. The developer makes the notice readable and ensures the submission result is clear.</p>

<h2>Plan delivery and failure handling</h2>

<p>A form that displays "success" should create a durable record or confirm that the destination accepted the message. Email alone can fail because of filtering, DNS changes, provider limits, or a full mailbox. Use server-side validation, spam controls that do not block keyboard users, delivery monitoring, and a documented fallback.</p>

<p>Test the intake route on mobile and with assistive technology. The person submitting should receive a useful confirmation that states what happens next without promising a response the firm cannot meet. Staff need an alert when delivery fails and a way to review submissions without sharing mailbox credentials.</p>

<h2>Accessibility review</h2>

<p>People may need legal information while under time pressure or while using a screen reader, keyboard, magnification, or voice input. The U.S. Department of Justice publishes <a href="https://www.ada.gov/resources/web-guidance/">website accessibility guidance</a> for businesses open to the public. The W3C recommends using the current <a href="https://www.w3.org/WAI/standards-guidelines/wcag/">WCAG 2 standard</a> when developing or updating accessibility policies.</p>

<p>At minimum, review heading order, link purpose, keyboard operation, focus visibility, form labels, error messages, contrast, text resizing, image alternatives, and document accessibility. Automated scanning helps locate some problems. Keyboard and screen-reader testing find issues that scanners miss.</p>

<h2>Privacy and analytics checklist</h2>

<ul>
  <li>Inventory every form field, tracking script, call-tracking tool, chat widget, and embedded service.</li>
  <li>Document where submissions go, who can access them, and how long each system retains them.</li>
  <li>Collect the minimum data needed for the stated intake purpose.</li>
  <li>Configure analytics and advertising tags according to the firm's approved consent and privacy approach.</li>
  <li>Keep private inquiry details out of analytics event labels, URLs, and application logs.</li>
  <li>Review vendor contracts and settings with the firm's privacy and security advisers.</li>
</ul>

<h2>Technical SEO and launch review</h2>

<ul>
  <li>Give every indexable page a unique title, description, H1, and canonical URL.</li>
  <li>Link practice pages to relevant attorneys and link biographies back to relevant services.</li>
  <li>Redirect replaced URLs one-to-one where a genuine equivalent exists.</li>
  <li>Keep drafts, search results, internal thank-you pages, and private portals out of search indexes.</li>
  <li>Validate structured data against the visible page and omit reviews or locations the firm cannot verify.</li>
  <li>Test the XML sitemap, robots rules, error pages, social previews, and mobile layout.</li>
</ul>

<h2>Ownership after launch</h2>

<p>Assign a person to each practice page, attorney biography, office detail, disclaimer, and intake workflow. Set review dates based on how often the facts change. The maintenance plan should cover software updates, backups, uptime, form delivery, broken links, accessibility checks, and content changes.</p>

<p>Terry Hunt Dev provides <a href="/services/nextjs-development">Next.js development services</a> for sites that need clear service information, dependable intake paths, maintainable publishing, and careful technical implementation. If your firm is planning a new site or repairing an existing intake flow, <a href="/contact">request a law firm website consultation</a>. I can help turn the firm's approved content and requirements into a site the internal team can operate.</p>

Plan law firm website content and intake paths with a checklist for practice pages, attorney bios, privacy, accessibility, disclaimers, and SEO.

Law Firm Website Content and Intake Checklist

A practical pre-launch checklist for law firm content, intake, accessibility, privacy, and technical review.

Plan practice pages, attorney bios, intake forms, accessibility, privacy, and launch review.

Law Firm Website Content Checklist

<p>A Strapi multi-site setup uses one content platform to support more than one website, brand, region, or audience. The hard part is not adding a <code>site</code> field. The hard part is deciding which content is shared, which content must stay separate, and which editors can publish to each destination.</p>

<h2>Choose the ownership model first</h2>
<p>Before building content types, list the sites and the people responsible for them. Decide whether each site shares legal ownership, infrastructure, release schedules, security requirements, and editorial governance. Separate Strapi instances are often safer when organizations have different administrators, compliance boundaries, or failure tolerance.</p>
<p>A shared instance is a better fit when one team governs the sites, content reuse has clear value, and the organization accepts a shared operational dependency.</p>

<h2>Three practical Strapi multi-site patterns</h2>
<h3>1. Site relation on each entry</h3>
<p>Create a <code>Site</code> collection with fields such as name, key, domain, locale defaults, theme reference, and publishing status. Content entries relate to one or more sites. The frontend requests entries for its site key.</p>
<p>This pattern is explicit and easy to query. It also requires validation so editors cannot publish an entry with missing or conflicting site relationships.</p>

<h3>2. Shared entries with site-specific overrides</h3>
<p>Keep reusable information, such as an organization description or service definition, in a shared entry. Store site-specific title, introduction, call to action, or metadata in related override records. This reduces copied content while preserving local or brand-specific language.</p>
<p>Use overrides only for fields that need them. A content model with an override for every field becomes harder to understand than separate entries.</p>

<h3>3. Separate instances with a shared frontend package</h3>
<p>Some organizations should keep content and permissions in separate Strapi instances while sharing frontend components, schemas, and deployment tooling. This costs more to operate but reduces the effect of one site's publishing or infrastructure problem on the others.</p>

<h2>Example content model</h2>
<pre><code>Site
- name
- key
- primaryDomain
- defaultLocale
- active

Page
- title
- slug
- site (relation)
- pageType
- sections (dynamic zone)
- seo (component)
- publishStart
- publishEnd

GlobalSetting
- site (relation)
- navigation
- footer
- contactDetails
- defaultSeo</code></pre>
<p>Use a composite rule in application logic for <code>site + slug</code>. A slug that is unique in one site may be valid in another, so a global slug rule can block legitimate pages.</p>

<h2>Query by site, not by hostname alone</h2>
<p>The frontend should resolve the current site from controlled configuration, then request content with that site key. Do not trust an arbitrary request hostname to select private content. Preview and webhook endpoints need the same site validation.</p>
<p>Cache keys and revalidation tags should include the site identifier. Otherwise, publishing one site's page can invalidate or overwrite another site's cached response.</p>

<h2>Roles, permissions, and editorial boundaries</h2>
<p>Strapi roles can limit administrative actions, but the exact site-level permission model needs testing against your Strapi edition and workflow. If editors must be isolated from other brands or legal entities, confirm that the required restrictions apply in the admin interface and API. Use separate instances when the boundary cannot be enforced and audited.</p>

<h2>SEO requirements for every site</h2>
<ul>
  <li>Generate canonicals from the correct domain and route.</li>
  <li>Keep XML sitemaps separate by hostname.</li>
  <li>Store site-specific titles, descriptions, social images, and robots directives.</li>
  <li>Use structured data that names the correct organization and visible service area.</li>
  <li>Prevent preview, duplicate-domain, and inactive-site URLs from being indexed.</li>
</ul>
<p>Shared content does not mean every site should publish the same page. Each site needs a reason for the page and enough distinct information to serve its audience.</p>

<h2>Deployment and recovery planning</h2>
<p>A shared Strapi instance creates a shared dependency. Review database backups, uploaded media, environment separation, migrations, restore testing, rate limits, monitoring, and the effect of a failed deployment on every site. Record how each frontend behaves if the CMS is unavailable.</p>

<h2>Questions to answer before building</h2>
<ul>
  <li>Which content is shared, localized, or owned by one site?</li>
  <li>Can an editor see or change another site's content?</li>
  <li>Who approves global changes?</li>
  <li>How are domains, redirects, previews, and sitemaps generated?</li>
  <li>Can one site deploy or recover without the others?</li>
</ul>
<p>A short architecture review can answer these questions before the content model hardens around the wrong ownership assumptions. See <a href="/services/strapi-development">Strapi development services</a> for implementation help and the <a href="/portfolio/railway-and-strapi-projects">Strapi and Railway portfolio</a> for related project context.</p>

Plan a Strapi multi-site CMS with site relations, shared content, permissions, routing, SEO controls, cache isolation, deployment, and recovery.

Technical SEO Resources & Benchmarks

A Day Spent Auditing Technical SEO

Building SEO and Structured Data Fields in Strapi

My Checklist for Migrating Content into Strapi

Website Maintenance Costs: A Practical Checklist for Small Businesses

Law Firm Website Content and Intake Checklist

How to Structure Strapi for Multiple Websites

Need hands-on help with Technical SEO?