---
name: commercial-cleaning-website
description: Blueprint for building a full commercial cleaning / janitorial company website (complete page structure, technical and local SEO, GEO / AI-search, schema markup, sitemaps, trust proof, lead form). Use when the user asks to build, template, or clone a website for a commercial cleaning, janitorial, office cleaning, or facility services business.
---

# Commercial Cleaning Website Blueprint

Replicate the complete cleaning-site structure, not another company's identity or claims. Build the pages below in the first pass; refine with owner evidence. Preserve an existing site's approved design and content during unrelated changes.

**Example build:** [JPSK Commercial Cleaning](https://jpskcommercialcleaning.app/) (Miami-Dade) is the reference site this blueprint was built from. Study it for page types, structure, depth and quality bar. Never copy its company facts into another business (see Honesty and portability).

## Inputs and workflow

1. Ask only for missing company name, HQ city/county, Google Business listing link (if any), and brand vibe or brand book. Reuse supplied answers and assets.
2. Treat the owner's brand book as authoritative over this blueprint: logo variants, fonts, colors, forbidden language, service area and exact CTA. Without a brand book, choose a distinctive professional direction and use one consistent walkthrough CTA.
3. Inventory confirmed facts, unknown facts, photos, videos and PDFs. Ask for the ten buyer-trust answers below in one grouped round; do not block page construction on missing answers.
4. Centralize content and images, create every hub/detail route, then build shared public-page templates and secure inquiry handling.
5. Add SEO, navigation, visual motion and document downloads. Verify the page list and real inquiry flow before reporting completion.

## Honesty and portability

- Never copy JPSK's address, contacts, insurance limits, credentials, personal experience, policies, testimonials, product brands or audit commitments into another company as fact.
- Mark invented scenario content visibly **Sample**. Mark unknown business facts **Pending owner confirmation**; do not invent phone numbers, ratings, client names, job vacancies or statistics.
- Apply owner confirmations precisely. Remove pending wording for confirmed facts across the authorized surfaces; do not infer confirmation of unrelated claims.
- Distinguish the owner's years of experience from company age. Feature only approved services, industries and geographic coverage.
- Use official organization logos only after the owner confirms the credential; otherwise use neutral labeled targets. Distinguish memberships, firm certifications and worker training. OSHA compliance training is not OSHA 10/30 completion; IICRC technician training is not automatically firm certification.
- Never present AI-generated or dramatized videos as genuine client testimonials. Inspect supplied clips for synthetic content or watermarks; ask about authenticity when uncertain. An owner request to embed a clip does not verify it as a real review.
- Prefer real job photos with permission. Generated imagery must be visibly labeled illustrative, not a real crew, site or result. Tell the owner and offer real-photo replacement before publication.
- Read every supplied PDF before extracting its program. If branded for another business, confirm reuse/rebranding authorization; do not carry its guarantees into the new business by default.

## Required sitemap

Build the following content routes plus search-support endpoints. Use roughly five services, five approved industries, 10–15 actual communities and at least three sample scenarios and resources when the owner has not supplied final content.

### Home and company

- `/`: Full-bleed cleaning photograph, brand/company-led H1, literal commercial-cleaning category and service-area signal, exact CTA; straight answer; compact service cards; industries; verified proof; testimonials; compact credentials; scenario links; map/contact; buyer-trust FAQs; final CTA. Show ratings/count-up statistics only when verified. Make the first screen a useful site experience, not an explanatory dashboard.
- `/about`: Owner introduction video, personal experience, company story, values and team grid. Label unknown portraits, names and biographies; do not manufacture a founding story. Reuse confirmed insurance, screening and audit facts.
- `/careers`: Confirmed openings or clearly labeled sample roles, shifts/requirements/pay only when supplied, application contact and optional Spanish section where appropriate.

### Services and industries

- `/services` + `/services/$slug`: Janitorial, detailed deep cleaning, floor care, window/glass and post-construction are starting categories, not promised offerings. Hub cards have matching pictures, compact spacing and no redundant decorative icons. Detail pages have a service-specific title photo, direct answer, proposed/confirmed task scope, scheduling/frequency, substantial facility-specific copy, FAQs and CTA.
- `/industries` + `/industries/$slug`: Offices/coworking, medical offices/urgent care, schools, houses of worship and warehouses are starting candidates. Substitute only approved industries; do not feature hospitals, manufacturers or data centers without relevant references and owner approval. Each detail has its own facility photo, direct answer, planning considerations, access/calendar/privacy requirements, longer overview and quality-process link. Do not invent a proof count. Medical copy must not imply unsupported health outcomes; school screening claims require confirmation.

### Communities

- `/areas-served` + `/areas-served/$slug`: Cover actual communities in the approved service area. Each detail has a locality-specific title photograph, unique title/description, breadcrumb, local answer, community notes, local service notes, local contact/CTA, three unique FAQs and nearby links.
- Add a warm “Why we love serving [community]” section using accurate public landmarks and business characteristics. Research unfamiliar places. Do not invent personal favorites, local client relationships, response-time advantages or a branch office; ask the owner to supply genuine favorites.
- Generated city scenes are illustrative, not authenticated landmark photography. Do not describe an imagined scene as an exact local landmark.

### Reviews and buyer proof

- `/reviews` (nav label **Testimonials**): Genuine client videos, written reviews and verified Google rating/listing link. Unknown written reviews remain visibly pending; do not show stale “video pending” copy when approved real clips are present.
- Preserve actual video aspect ratios: 9:16 portrait, 16:9 landscape. Portrait testimonial grids: four columns on wide desktop, two on tablet, one on narrow phone; keep embedded controls usable. Use accessible iframe titles, fullscreen permission and lazy/click-to-play loading. Prefer poster cards with the iframe loaded on click when a genuine poster is available; do not invent one. Owner introduction remains independently framed.
- `/review`: Google review action using the confirmed Place ID. Until supplied, show the listing dependency rather than a broken/fabricated destination.
- `/case-studies` + `/case-studies/$slug`: At least three different industry scenarios; challenge, approach and results. Samples are not completed projects. Real results require client permission, dates, real photos and evidence.
- `/credentials`: “Insured. Screened. Trained.”; confirmed insurance/bond limits and certificate process; a visual organization-logo grid with verification links and accurate status. Candidate organizations: CIMS, GBAC STAR, ISSA, Green Seal GS-42, OSHA 10/30, IICRC, BSCAI and BBB. Do not imply all are held. Link to audit and products programs.
- `/comparison`: Three-column **Criteria / [Brand]'s current answer / Proof to request** table. Compare evidence without naming or disparaging competitors. Use the specific evidence list below, not a repeated generic placeholder. Keep section-only answer overrides separate from shared policies when the owner restricts the edit to comparison.

### Quality audit and products

- `/cleaning-audit`: Dedicated quality-process page, title photograph, audit frequency/responsibility, supervisor and account-review cadence, zone/checkpoint breakdown, score bands, corrective-action timing, photo records, sign-off and escalation. All commitments come from the owner's process document.
- For an owner-approved 57-point program, publish all 57 checkpoints and seven zones, use readable zone accordions, distinct score-band indicators with text labels, and a downloadable branded checklist. Copy thresholds/timing exactly from the approved source; do not assume this business uses JPSK's thresholds.
- Provide a usable downloadable PDF with zone totals, final score, date/facility, auditor sign-off and corrective-action fields. Link it prominently and verify the actual download; inspect every page for cut-off text and score/table layout.
- `/products-supplies`: Separate page rather than burying detail in Credentials. Link from Credentials, audit and footer. Include selection rules, task-by-task products, consumables, equipment, approved alternatives/allergy requirements, SDS/label/dilution safety, replenishment and audit tie-in. Publish named chemicals or performance/contact-time claims only from approved sources and current manufacturer labels.
- Use a supplies/equipment title photo; separate consumables and machine photos beside their lists. Keep lists and photos balanced without forcing fixed-height text. Pair concise rule lists, readable tables and compact repeated items. Label generated equipment scenes illustrative rather than “actual kit.”

### Contact and supporting pages

- `/contact`: Confirmed contact details, embedded map, grouped service/schedule/area/pricing FAQs and shared trust policies. Do not invent operating hours or booking availability.
- `/request-assessment`: Inquiry form collecting name, email, optional phone, company, facility type, city, approximate size, requested service, preferred schedule and message. A submission is not a confirmed appointment, price or contract.
- `/resources` + `/resources/$slug`: At least three practical facility-manager guides with substantive topic-specific copy, image, comparison table and interactive review checklist.
- `/privacy`, `/terms`: Clearly identified drafts until approved; accurate inquiry use/access, retention/contact dependencies, service scope, supplies, insurance and cancellation terms. Do not invent legal commitments.

## Buyer-trust answers and evidence

Collect standalone answers to all ten questions; retain exact amounts, timing, inclusions and notice periods. Unknown answers remain pending, or visibly Sample only when the owner requests examples.

| Question to answer | Specific proof to request |
| --- | --- |
| Liability, workers' compensation, bond, certificate availability | Certificate of insurance naming your facility |
| Screening and training hours/topics | Background-check and training records, subject to lawful privacy protection |
| Supervision and employee/subcontractor arrangement | Crew photo roster and W-2/employment confirmation, with sensitive data redacted |
| Similar-business references and permission to contact | Three contacts you may call, only when available and authorized |
| Missed visit, relief crew and makeup timing | Written backup-crew and makeup-visit policy |
| Written task scope, frequency and exclusions | Signed line-item scope of work |
| Supplies/equipment/consumables and charges | Consumables list with pricing |
| Inspection frequency, logs and corrective action | Sample checklist and inspection report |
| Monthly price, inclusions, extras and billing | Written quote with inclusions and billing terms |
| Initial term, cancellation notice and fees | Agreement showing notice period and fees |

Reuse confirmed policies in home/contact FAQs, Credentials, About proof, service/community answers, Terms and inquiry form. Roll out a confirmation site-wide only when authorized. Never silently collapse distinct cancellation terms or add a response-time guarantee.

## Visual system and architecture

- Every page title has a photographic background, including all services, industries and supporting pages. Use a shared title default plus centralized service/industry/location image maps so no title falls back to a plain band. Preserve custom products/location images. Use a readable brand-colored overlay, concise intro and breadcrumb, with a small truthful illustration label where needed.
- Use bold brand typography and semantic CSS tokens for colors, overlays and shadows. Respect supplied fonts/logos; do not impose JPSK's palette on other companies. Avoid generic AI gradients, oversized empty cards, card-inside-card sections and redundant decorative icons. Keep repeated cards compact.
- Add subtle image drift, scroll reveal/stagger, photo zoom and restrained item motion. Respect reduced motion and ensure content remains visible if observers/scripts fail. Keep headers and next-section content visible without excessive title height; wrap long H1s on small screens.
- Header: Services, Industries and Areas Served dropdowns with “All …” links; keyboard/focus access on desktop, accessible accordion/drawer on phones. Include Quality audit, About and Testimonials. Footer: Services, Company, Connect, comparison, audit and products links.
- On TanStack Start, use shared browser-safe data/templates and sibling hub/detail leaf routes (underscore filename convention). Keep each leaf's own metadata; do not create an alternate router or duplicate `/` route. Follow platform server-runtime, server-function and schema guidance before backend work.
- Save inquiries through a validated public server function into an RLS-protected table: anonymous insert only, database-enforced per-email rate limits, staff-membership-gated reads, explicit grants and no public record retrieval. Never use a privileged client for ordinary reads. Use generic safe errors that do not reveal whether a lead exists.

## SEO, local search and GEO / AI-search

These are first-pass requirements, not an optional finishing package. GEO means generative engine optimization: make accurate public information easy for AI-search systems to retrieve and cite. Neither SEO nor GEO guarantees indexing, rankings, rich results or AI citations. Follow the platform's current head, sitemap, runtime and schema guidance when implementing; do not substitute outdated recipes.

### Search intent and content architecture

- Map each approved service, industry and community to a distinct search intent and public page. Research relevant commercial-cleaning terms, local intent and real buyer questions using available keyword/search tools; do not invent search volumes or competitor findings. Do not block construction when paid research tools are unavailable.
- Use descriptive stable slugs, one clear page-topic H1, logical H2/H3 hierarchy, useful introductory answers and natural brand/service/location wording. Avoid keyword stuffing, arbitrary word counts and duplicated city-name-swapped doorway pages. Build location pages only for genuine coverage with substantial unique local information.
- Connect home to hubs, hubs to details, and details to relevant services, industries, communities, audit, products and inquiry pages. Add visible breadcrumbs and meaningful anchor text. Every public detail page must be reachable through ordinary crawlable links, not only a search box, dropdown script or sitemap.
- Give resources and genuine case studies identifiable authors where supplied, relevant firsthand evidence, primary-source links and genuine publication/update dates. Label sample scenarios; do not manufacture authors, expertise, results or dates.

### Page metadata and crawlable rendering

- Give every content leaf, including `/`, a unique app-specific title, description, `og:title`, `og:description`, appropriate `og:type` and `twitter:card`. Titles state the page subject plus brand and location where useful; descriptions truthfully summarize that page rather than repeat a generic slogan. Preserve owner-approved wording.
- Use TanStack route `head()` with title inside `meta`, not a top-level title field. Put one self-referencing canonical in each leaf's `links` and its matching `og:url` in `meta`; never place a canonical on the root/layout because links concatenate. Root holds sitewide defaults only. Until a public domain exists, use relative canonical and `og:url` paths; never bake a preview or placeholder domain into source.
- Add matching `og:image`/`twitter:image` only on the leaf and only for the meaningful image that page shows at an absolute HTTPS URL. Use a share-sized rendition around 1200×630 and a few hundred KB; omit relative/bundled image URLs and fabricated images. Do not add social images to root/layout routes. A new generated social image requires owner approval.
- Render substantive public copy, links, headings and metadata in server HTML. Do not make business content depend on client-only rendering, scroll observers or iframe content. Keep titles, descriptions and schema page-specific for dynamic slugs; return a real 404 for unknown slugs rather than a successful empty page.
- Keep approved public pages indexable. No sitewide `noindex` or wildcard crawler block unless explicitly requested. Private staff areas and inquiry records must remain access-controlled; robots.txt is not security. For a requested hidden public page, apply page-level `noindex` and exclude it from the sitemap; do not block crawling if a crawler must read its `noindex`.
- If URLs are renamed, preserve internal links and implement permanent redirects with no chains or loops. Use consistent HTTPS and preferred hostname after the domain is connected. Add reciprocal `hreflang` only for real translated equivalents with self-canonicals, not automatically for English-only sites.

### Sitemap, robots.txt and optional llms.txt

- Keep public-route inclusion decisions centralized and consistent with the router. Include the homepage, approved hubs/details and other indexable canonical content; exclude private/auth/API paths, inquiry records, redirects, errors and noindex pages. Dynamic public content lists must paginate and surface query failures rather than silently emit partial XML.
- Preserve an existing sitemap implementation. For ordinary route changes with the router-derived generator installed, set the required `staticData.sitemap` decision on each route and preserve subtree exclusions. For new installation or an approved migration, read `knowledge://seo/sitemap/install.md` first; if unavailable, report the missing recipe instead of inventing a helper.
- Create or migrate `/sitemap.xml` only once a public project URL is known. Use absolute URLs for the actual public host, valid escaped XML and the XML content type. Never substitute a preview/project-ID host. Preserve existing sitemap files and base URLs while a new public domain is unknown; list a missing sitemap as unresolved rather than claim completion.
- Use `<lastmod>` only for authoritative page-specific significant-content timestamps; omit current-date/build-time/generation-time fallbacks. Do not invent dates. Split oversized sitemaps at the protocol limits of 50,000 URLs or 50 MB uncompressed with a sitemap index when needed.
- Maintain `public/robots.txt` in place and preserve user-agent rules. Create it for the requested full-site setup with `User-agent: *` and `Allow: /` unless restrictions were requested. Add a `Sitemap:` directive only when the sitemap and public URL exist; remove it when deliberately blocking all crawlers. Do not create competing static and dynamic endpoints.
- Provide `/llms.txt` as an optional experimental public-content summary, not a standard required by Google or a guarantee of AI discovery. Include verified company/service/area facts and links to key public pages; never expose leads or staff-only data. Keep it consistent with visible content and robots policy. Do not change AI-crawler permissions without the owner's authorization.

### Structured data: accurate JSON-LD by page type

- Use route `head().scripts` with `type: "application/ld+json"` and safe serialization. Structured data must describe visible content and confirmed facts. Centralize the business entity and use stable linked `@id` values once the public domain is known; never fabricate domains, addresses, hours, prices, credentials, reviews or missing schema fields just to satisfy a validator.
- Home/company entity: `LocalBusiness` (or a valid more-specific type only when applicable), with confirmed name, public contact information, logo, URL, `areaServed`, Maps link and verified `sameAs` profiles. Use `WebSite` for site identity and `WebPage` for pages where useful. Do not invent a CleaningService schema type or branches for every service-area city.
- Services: `Service` with name, actual scope/description, linked provider and approved `areaServed`. Use `Offer` only for a real visible offer with confirmed terms; do not mark a service as `Product` merely to chase rich results. Industry/community pages may describe the actual service offered and approved locality, without creating fictitious local businesses.
- Hubs: `CollectionPage` and an `ItemList` of actual linked items where useful. Deep pages: `BreadcrumbList` matching the visible hierarchy and real destinations.
- Resource articles and genuine case-study narratives: appropriate `Article` with confirmed author/publisher and real dates when available. Mark sample case studies visibly; never encode fabricated client outcomes as evidence.
- Genuine embedded videos: `VideoObject` only when the required real name, description, usable thumbnail URL and actual upload date are available; use the correct embed URL and duration when known. Never invent thumbnail/date fields or imply synthetic testimonials are client evidence.
- Careers: `JobPosting` only for a genuine current vacancy with confirmed job details and an application path; never add it to sample roles or a generic careers hub. Remove or expire markup when the opening closes.
- Do not add `FAQPage` solely as an SEO improvement; preserve valid existing FAQ markup and require exact agreement with visible questions/answers when specifically used. Cleaning businesses should not expect Google FAQ rich results. Do not promise self-serving LocalBusiness review stars, even with an embedded third-party widget; never add fabricated or scraped aggregate ratings. Review schema must meet the search engine's current eligibility policies.
- Validate both syntax/vocabulary and search-engine eligibility: Schema.org Validator for general schema, Google Rich Results Test for supported features. Unsupported rich-result types do not make useful valid schema invalid. Report missing owner facts instead of falsifying them.

### Local business and trust signals

- Keep verified name, address, phone, email and service areas consistent across contact, footer, structured data, downloadable documents and public summaries. Respect a service-area business's hidden/private address; do not publish it simply to fill schema. Never create invented offices, map pins, local clients or response-time advantages.
- Embed Google Maps using the confirmed business listing or correct approved public location; provide a normal Maps link and accessible frame title. A map embed alone does not verify the listing. Link the Google review action to the confirmed listing/Place ID. A live review widget needs an authorized supported provider, accurate attribution and compliant data use; do not promise it without setup or scrape Google reviews.
- Recommend Google Business Profile verification and accurate categories, service areas, services, hours, photos and website URL after owner confirmation. Genuine reviews and consistent legitimate directory profiles support trust; no purchased reviews, fabricated ratings or bulk spam citations. Connecting/verifying the listing is an external dependency until actually completed.

### GEO: useful answers and citation-ready evidence

- Open home/service/industry/community pages with a concise standalone answer to what the company offers, whom it serves and where. Use real buyer questions as headings with direct answers, useful lists, comparison tables and follow-up detail. Repeat the necessary subject/location so excerpts stand alone, without mechanical keyword repetition.
- Explain scope, frequency, cost drivers, inclusions/exclusions, safety, inspections and cancellation from confirmed policies. Quote price ranges only when approved; otherwise explain the quote process and relevant variables. Link to downloadable audit checklists, approved product sources and credential verification rather than make unsupported authority claims.
- Provide crawlable summaries and owner-approved transcripts for genuine videos; important answers must not exist only inside a player or PDF. Keep audit checkpoints and product guidance in accessible page text alongside downloads. Do not invent spoken words or present synthetic clips as genuine testimony.
- Cite accurate primary sources for locality facts and technical/product claims. Maintain consistent business/entity naming and clear authorship where verified. Update materially changed answers and stale claims across their shared surfaces. Do not add hidden AI-targeted text, special “AI schema,” fake citations or promises of inclusion in ChatGPT, Gemini, Perplexity or AI Overviews.

### Performance and accessibility

- Aim for good Core Web Vitals: LCP ≤2.5 seconds, INP ≤200 ms and CLS ≤0.1 at the 75th percentile of real visits. Lab checks are diagnostic, not proof of field performance or a ranking guarantee.
- Prioritize the visible title/hero photo with responsive sizes, explicit dimensions/aspect ratio and high fetch priority when appropriate; do not lazy-load the LCP image. Compress photos, lazy-load below-fold media, reserve embed space and avoid loading every third-party player/widget immediately.
- Keep animations lightweight, preserve reduced-motion behavior, minimize unnecessary scripts and font variants, and prevent layout shifts. Use meaningful image alt text describing the actual photo, not keyword stuffing or copied meta descriptions. Provide keyboard access, readable contrast, labeled forms and accessible media without sacrificing crawlable content.

### SEO verification and post-publication handoff

- Inspect server-rendered HTML and rendered page state for every public route: unique head tags, one self-canonical, matching `og:url`, expected indexability, visible H1, crawlable links and accurate JSON-LD. Check unknown slugs return 404, intended redirects work and no public pages are orphaned.
- Once a public domain/sitemap exists, fetch robots.txt and sitemap.xml; verify successful responses, content types, absolute public URLs, inclusion/exclusions and truthful lastmod values. Validate representative schemas for each page type and investigate the current SEO scanner findings rather than mark fixes from source assumptions alone.
- Test mobile layouts, image/iframe loading and performance; distinguish measured results from unverified targets. Report separate states for code-ready, published, externally verified and blocked work. Never equate publishing or sitemap submission with confirmed indexing.
- After publication, recommend connecting/verifying Google Search Console and optionally Bing Webmaster Tools, submitting the actual sitemap and inspecting representative URLs. Verify settings through available authorized tools when requested; otherwise list owner actions explicitly. Metadata changes reach a live URL only after the next publish; publish only on explicit request.

## Verification and handoff

- Check every route resolves independently, every title image loads, all navigation/nearby/resource links work and metadata/structured data match visible content.
- Test confirmed policy values on every reused surface, comparison proof cells, image-map completeness, inquiry validation/rate limits and unauthorized-read denial.
- Drive the real inquiry flow end-to-end: submit valid input, verify authorized read-back, and remove only the identifiable test record. A signed-out or demo-only check is not sufficient.
- Inspect desktop, tablet and 390px phone layouts: long H1s, picture labels, menus, table scrolling, card spacing, portrait players and reduced-motion states. Check rendered screenshots, runtime errors and current build output, not source alone.
- Verify all organization logos and downloads load; inspect exported PDF pages. Do not claim a player plays unless observed playing.
- Hand off a concise inventory of remaining samples, unconfirmed facts, actual photos needed, Google listing/Place ID, legal approvals and domain dependencies. Do not call a blocker complete. Recommend Search Console verification and sitemap submission after publication; publish only on explicit request.