SEO and Indexing FAQ — How WarmySender's pages get indexed
This FAQ explains how WarmySender pages get discovered, crawled, rendered, and indexed by Google and AI assistants. If you're curious why a specific page isn't showing up in search yet — or why a shared link's preview looks the way it does — read on.
How our SEO works in plain English
WarmySender uses a hybrid SSR + SPA architecture. When a search-engine crawler (Googlebot, Bingbot, ClaudeBot, GPTBot, PerplexityBot, etc.) visits a page, our server renders the full HTML server-side with all the right meta tags, structured data (JSON-LD), and content already in place. When a real human visits in a browser, we serve a lightweight SPA shell and the React app hydrates client-side, with a custom useHead hook setting page-specific title, canonical, and Open Graph tags after mount.
The SSR-for-crawlers path is the canonical path for Google. Our crawler detector at server/ssr/crawler-detector.ts matches Googlebot, Bingbot, every AI crawler we've encountered, and social-share preview bots (Twitterbot, LinkedInBot, Slackbot, WhatsApp, etc.). Those user agents get the full SSR template every time.
The SPA + useHead path is for human visitors. The useHead hook (client/src/lib/use-head.ts) replaces the older react-helmet-async library, which had a silent context-split bug under Vite's bundle chunking — see Key Lesson GL#283 for the full story. After the May 16, 2026 fix, every route in a real browser now correctly displays its own page title, canonical, and og: meta on every share.
Why pages don't appear in Google immediately
Indexing has four stages: Discovery → Crawl → Render → Index. Each stage can take days to weeks. A brand-new page typically takes 2-4 weeks to make it through, even with a healthy site. Common reasons a page is stuck:
Discovered, currently not indexed — Google knows the URL (via your sitemap, hreflang annotations, or external backlinks) but hasn't crawled it yet. This is normal for low-traffic sites or large sitemaps. The fix is patience, plus making sure the page has at least one strong internal link from an already-indexed page.
Crawled, currently not indexed — Google fetched the page but decided not to index it. This usually signals a quality concern: the content is thin (under 300 words), near-duplicate of another page, or doesn't have unique value over what's already indexed. The fix is content quality — make the page substantively different from competitor pages on the same topic.
What 'Discovered, currently not indexed' means on a WarmySender URL
For a WarmySender blog post or comparison page, this usually means one of three things: (1) the post is new and Google hasn't gotten to it yet (wait 2-4 weeks); (2) the post is in a low-priority section without strong internal links from your sitemap-included pages; or (3) Google flagged the post as low-uniqueness and chose not to index it relative to the competition. We monitor every page's indexing status in our admin dashboard.
What 'Soft 404' means
A Soft 404 means Google fetched a 200 OK response from the URL but the content didn't deliver what the URL implied. Common case on WarmySender: a localized URL like /it/blog/features that, prior to May 16, 2026, silently 301-redirected to /blog/features (English). Google followed the redirect, saw English content at a URL that promised Italian, and flagged it as Soft 404 because the locale was lost mid-redirect. Post-fix, those URLs return clean HTTP 404 when the underlying database has no Italian translations for that category — Google now sees an honest 404 and drops the URL from the discovery loop. See GL#285 for the full evergreen pattern.
How i18n pages work
WarmySender supports 10 locales: ar, de, es, fr, it, ja, ko, nl, pt-BR, zh-CN. Each locale's category index page (/<locale>/blog/features, /<locale>/blog/compare, etc.) renders if at least one translated row exists in the database for that category and locale. If zero rows, the page returns 404 instead of redirecting to English. The sitemap is content-gated the same way — empty (locale, category) combinations are never advertised. When translations later ship, the page automatically starts returning 200 — the gate is data, not code.
Individual translated blog posts (/<locale>/blog/posts/<slug>) work the same way: they exist only when the database has a row for that (slug, locale) pair. hreflang annotations on the English version of each post point to siblings in every locale where a translation exists; locales without a translation are correctly absent from hreflang.
How to share a WarmySender page on LinkedIn or X correctly
When you share a URL on LinkedIn, X (Twitter), Slack, WhatsApp, or Discord, those platforms send a preview-bot to fetch the page and extract the og:title, og:description, og:image, and twitter:card meta tags. Because we serve crawlers and browsers from different paths, both paths now emit the same per-page og: tags after the May 16, 2026 fix. Pre-fix, every WarmySender URL shared on social media showed the homepage's generic preview ('WarmySender | Cold Email, Email Warmup, LinkedIn & Multichannel Outreach') because the broken Helmet library couldn't override the index.html defaults. Post-fix, the preview shows the actual article title and description.
If you're sharing a link and the preview looks wrong, check these in order: (1) the platform may be using a cached preview from before the fix — most platforms refresh after 24 hours; (2) the URL itself is correct (no typos that route to a different page or 404); (3) the page is actually indexed (paste it into Google's URL Inspection tool in Search Console to see what Google sees). If the og: tags look correct in the page source but the preview still looks wrong, force a refresh on the platform side (LinkedIn has a Post Inspector tool, X has Card Validator, Facebook has a Sharing Debugger).
What 'Page with redirect' means
A URL flagged as 'Page with redirect' means Google followed a 301/302 redirect from this URL to a different URL, and is now choosing to index the destination instead of the source. For WarmySender, this happens when an old URL (like /compare/warmysender-vs-instantly) redirects to its current canonical (/blog/compare/warmysender-vs-instantly). The redirect itself is correct and intended — Google is just being explicit that it has transferred indexing signal to the destination.
The related 'Page with redirect — Validation FAILED' status (which we cleared on May 16, 2026 — see GL#284) means Google revisited the URL after a fix was claimed and still found it redirecting. The fix isn't 'remove the redirect' — that would break external links and bookmarks — it's 'remove every internal link to the old URL so Google stops re-discovering it via your own site'. Our CI sentinel server/scripts/check-no-redirect-source-links.ts now blocks any future commit that re-introduces an internal link to a legacy URL.
Reporting an SEO issue you spot
If you notice a page that should be indexable returning a 404, a sharing preview showing wrong information, or a page in Google that points at an old URL, please email [email protected] with: (1) the exact URL you visited, (2) the user agent (browser or share preview bot), and (3) a screenshot or HTML view-source of what you saw. We use these reports to extend the smoke test coverage — every confirmed issue becomes a new assertion in npm run seo:smoke so the same problem can't recur silently.