Conversation
There was a problem hiding this comment.
Pull request overview
This PR updates the marketing site to address audit-driven UX/SEO suggestions by clarifying the product’s connectivity/privacy model, adding “compatibility/setup” conversion helpers, improving social proof presentation, and adjusting routing/redirect behavior for static hosting.
Changes:
- Add compatibility + demo CTAs and custom pricing-page FAQ items to reduce buyer uncertainty.
- Refine copy across pages/FAQ to accurately describe “internet for signalling/auth, media stays local.”
- Update SocialProof layout/styling and adjust CloudFront + Gatsby config (404 handling, legacy redirects, robots config tweak).
Reviewed changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| marketing/src/pages/pricing.tsx | Adds compatibility CTA, screenshots, and a pricing-specific FAQ list. |
| marketing/src/pages/index.tsx | Adds compatibility/demo CTAs and a mid-page “reduce buyer risk” section. |
| marketing/src/pages/baby-monitor-without-wifi/index.tsx | Updates privacy/connectivity copy to match signalling/local-media model. |
| marketing/src/components/SocialProof/Section.tsx | Restructures social proof into metric cards + testimonials with captions and new CTA link. |
| marketing/src/components/SocialProof/style.scss | Styles new proof metrics and testimonial figure layout. |
| marketing/src/components/LandingPage/FAQSection/index.tsx | Clarifies “secure” FAQ answer around auth/signalling vs media relay/storage. |
| marketing/gatsby-node.ts | Adds Gatsby redirect definitions for legacy blog URLs. |
| marketing/gatsby-config.ts | Removes robots-txt host option line. |
| cloudformation/marketing/cloudformation.yml | Changes CloudFront custom error responses to serve 404s via /404.html instead of /index.html. |
| export const createPages: GatsbyNode["createPages"] = async ({ actions }) => { | ||
| for (const redirect of legacyRedirects) { | ||
| actions.createRedirect({ | ||
| ...redirect, | ||
| isPermanent: true, | ||
| redirectInBrowser: true, | ||
| }); | ||
| } |
There was a problem hiding this comment.
actions.createRedirect with redirectInBrowser: true typically only affects client-side navigation unless your hosting layer generates/serves redirect responses/pages from Gatsby’s redirect data. Given this site is deployed to S3/CloudFront (see cloudformation/marketing/cloudformation.yml), direct requests to these legacy fromPath URLs will likely still 404 unless you also implement redirects at the edge (e.g., in the CloudFront Function) or generate static redirect pages during the build.
| CustomErrorResponses: | ||
| - ErrorCode: 403 | ||
| ResponseCode: 404 | ||
| ResponsePagePath: /404.html | ||
| - ErrorCode: 404 | ||
| ResponseCode: 200 | ||
| ResponsePagePath: /index.html | ||
| ResponseCode: 404 | ||
| ResponsePagePath: /404.html |
There was a problem hiding this comment.
Switching the CloudFront CustomErrorResponses from serving /index.html to serving /404.html means unknown paths won’t load the Gatsby app anymore. If you’re relying on Gatsby createRedirect (or any client-side redirect logic) to handle legacy URLs, those legacy requests will now render the 404 page instead of redirecting unless you add explicit redirect handling at the edge (e.g., in RedirectToIndexIfRequired) or ship static redirect objects/pages for those paths.
No description provided.