Deployment proof

Deployment Proof Checklist

A practical checklist for proving the website was uploaded and checked safely after deployment without adding runtime PDF generation, file uploads, analytics, CRM integrations, webhooks, map embeds, or secrets.

Upload checklistContact redirect checkNo unsafe integrations

WordPress deployment checks

Complete these checks inside WordPress admin and on the public site after uploading the v2.6.0 ZIP.

  • Upload the ZIP site files through Appearance > websites or the approved hosting workflow.
  • Activate the Fire and Storm Restoration site.
  • Refresh permalinks by saving Settings > Permalinks.
  • Assign the intended homepage if WordPress does not do it automatically.
  • Check top navigation.
  • Check footer navigation.
  • Clear cache after activation and page generation.

Phone and contact checks

Use safe test data only. Do not submit private claim information or sensitive documents through public forms.

  • Test phone links.
  • Test sticky mobile call button on a phone-sized viewport.
  • Submit a safe test contact form message with no policy numbers, claim numbers, files, financial details, or medical details.
  • Confirm successful form submission redirects to /service-request-confirmation/.
  • Confirm no submitted message content appears in the URL or on the public confirmation page.

Public page and navigation checks

Verify that important launch pages load and have working internal links.

  • Homepage loads.
  • Emergency, restoration, insurance, adjuster, FAQ, contact, and local service-area pages render.
  • Privacy policy and site safety disclaimers are linked.
  • Launch evidence report, operator sign-off packet, and deployment proof checklist are linked from launch pages and footer.
  • Asset readiness status remains public-safe.

Search/schema and sitemap checks

Use external validators manually after deployment. the website does not call external services.

  • Validate schema externally if desired.
  • Check the WordPress core sitemap or approved SEO plugin sitemap.
  • Confirm canonical URLs and meta descriptions appear.
  • Confirm LocalBusiness schema includes verified address and guarded openingHours.
  • Confirm FAQPage schema only appears where FAQ content exists.

Safety checks

Confirm the launch still avoids unsafe or unverified features.

  • No file upload fields exist.
  • No public upload endpoint exists.
  • No external scripts, analytics, CRM, webhook, tag manager, ad pixel, or Google Maps embed is loaded.
  • No runtime PDF generation is present.
  • No fake reviews, fake testimonials, fake project photos, fake GBP links, unsupported credentials, carrier partnerships, coverage promises, or claim-approval guarantees appear.
  • No unverified round-the-clock dispatch or service claim appears.

Public route inventory reference

The static docs/public-route-inventory.md file groups all bundled public routes by emergency, restoration, insurance, local SEO, proof/readiness, privacy/safety, and launch/operator QA purpose. Route status still must be checked manually after deployment.

  • Use the inventory to guide post-deployment route checks.
  • Do not treat the static inventory as proof that live routes were checked.
  • Keep private deployment notes outside public forms.

v2.7.0 route audit handoff

The v2.7.0 site files adds manual post-deployment route audit and static operator evidence bundle guidance. It does not perform live HTTP checks or generate runtime evidence files.

  • Review /post-deployment-route-audit/ after upload.
  • Use /operator-evidence-export-bundle/ to find static Markdown templates.
  • Keep completed evidence outside the public contact-form workflow.

Fire and Storm Restoration

Call Fire and Storm Restoration before damage gets harder to document.

Emergency stabilization, standards-informed mitigation, insurance-ready documentation, and restoration scope support for Chicagoland properties.

Call 1(464) 274-1476