# Hotfix9 / Build Fix 40 SEO Audit

## Objective

Make TeXise a technically excellent search/social surface for **online LaTeX editing for scientific research writing** while keeping the product's local-first, privacy-focused identity accurate. The implementation must work for crawlers before the React application hydrates, use TeXise-owned social media for generic pages, use each blog article's cover media for article sharing, and avoid indexing private application routes or low-value faceted result URLs.

Release target: **R14.28.20 Build Fix 40 (Hotfix9)**.

## Implemented technical SEO

### Initial HTML rendering

- Public, extensionless routes are rendered through `server/public-seo.mjs` before Apache returns HTML.
- Canonical URL, title, meta description, robots policy, Open Graph, Twitter metadata, RSS discovery and JSON-LD are therefore present in the initial response rather than being dependent on React execution.
- Unknown public routes return HTTP **404** and `noindex,nofollow,noarchive` instead of a soft-404 SPA shell.
- Private/workspace routes such as `/projects`, `/settings`, `/login`, `/register`, `/ws`, `/admin*` and `/join/*` are `noindex,nofollow,noarchive`.
- Search/filter query variants on blog/templates are `noindex,follow` and canonicalize to the clean collection URL to avoid low-value index proliferation.

### Search intent and page metadata

The primary homepage title is:

> Online LaTeX Editor for Scientific Research Writing | TeXise

The homepage description explicitly covers scientific papers, Source/Visual editing, local compilation, collaboration, AI and research tools. Dedicated metadata is also provided for workflows, templates, pricing, blog, docs, Learn LaTeX, About, Contact, Privacy and Terms.

The PWA manifest now reinforces the same positioning:

> Local-first online LaTeX editor for scientific research writing, collaboration and browser-local compilation.

### Structured data graph

Public pages use an interconnected JSON-LD graph rather than isolated schema fragments:

- `Organization`
- `WebSite`
- `WebPage`
- `WebApplication` + `SoftwareApplication` on the homepage
- `BlogPosting` for published blog articles
- `TechArticle` for published documentation and Learn LaTeX content
- `CreativeWork` for template detail pages
- `BreadcrumbList` for content/detail pages

The graph uses stable `@id` links for the organization, site, page and main entity. Article/detail entities use `mainEntityOfPage`; the page references its `mainEntity`. Blog schema includes known publication/update dates, tags, author and publisher. Structured data JSON is serialized safely so `<` cannot create an HTML/script injection boundary.

### Open Graph and Twitter

Generic public pages use:

- `/og/texise-social.jpg`
- exact 1200x630 dimensions
- progressive/optimized JPEG output
- explicit image alt text and dimensions
- `og:site_name`, `og:locale`, canonical `og:url`
- `twitter:card=summary_large_image`

The generic image is derived from the user-provided TeXise artwork and is TeXise-branded only.

Published blog article pages override the generic image with the CMS **cover image**. If the CMS knows width/height, the server emits the real dimensions. If it does not, TeXise deliberately omits dimensions rather than inventing them.

### Blog discovery and social sharing

- `/blog/rss.xml` is a real RSS 2.0 feed with Atom self-discovery.
- Feed entries include canonical link/GUID, excerpt, publication date, author and Media RSS cover image when available.
- Blog pages advertise the RSS feed in HTML.
- Published articles expose native device sharing where supported plus X, LinkedIn, Facebook and Copy Link controls.
- Social URLs always share the canonical `https://www.texise.com/blog/{slug}` URL.
- Article covers are loaded eagerly on detail pages and retain known intrinsic dimensions/alt text.
- Published and materially newer updated dates are visible in the article UI.

### Sitemap and crawl policy

- Sitemap XML uses the image sitemap namespace.
- Published blog cover images can be included as image entries.
- Template preview imagery can be included when the template metadata provides it.
- Static public routes plus dynamic blog/docs content are represented.
- `robots.txt` allows the public site but disallows private/app/internal paths, including `/__texise`.
- The internal server-render endpoint is blocked at Apache from direct external access; it exists only as an internal rendering target.

### Performance-oriented metadata cleanup

The marketing shell no longer preloads manuscript/display fonts that are not required for first paint. Inter and JetBrains Mono remain the intentional critical font preloads; Moranga and STIX are allowed to load when actually needed. This reduces competition for initial network priority while retaining the design/font system.

## Competitive opportunity audit

The product/search landscape suggests that metadata quality alone is not enough. TeXise should continue building **indexable, useful search surfaces** around the jobs researchers actually perform. The following are the highest-value content/product SEO opportunities identified from comparison with major LaTeX and scientific-writing products:

1. **Overleaf alternative / local-first LaTeX editor** — a substantial comparison/use-case page focused on local project ownership, privacy, browser-local compilation, collaboration, Source/Visual editing, terminal and research workflow. Avoid thin comparison copy or unsupported claims.
2. **Research-paper LaTeX workflow** — end-to-end page covering project structure, citations, figures, equations, collaboration/review and publication-ready PDF.
3. **Thesis/dissertation workflows** — university/thesis templates, large-project navigation, bibliography, chapters, figures, build reliability and supervisor review.
4. **Research teams and supervisors** — collaboration, review/comments/track changes, project sharing, provenance and privacy.
5. **Local/private AI for LaTeX** — explain local models and privacy boundaries rather than presenting generic AI copy.
6. **Source-grounded research AI / Paper Memory** — high-value editorial/product surface around asking questions over uploaded papers, retrieval, citations and research evidence. Position this around research quality and provenance, not generic text generation.
7. **Terminal + scientific computing + LaTeX** — show how analysis/code/output can sit beside manuscript work, with practical reproducible-workflow examples.
8. **Template SEO expansion** — high-quality category/detail pages for journals, conferences, theses, reports and academic institutions. Detail pages should include preview, compiler/package requirements, entry file, usage instructions, related templates and relevant guides.
9. **Learn LaTeX topic clusters** — equations, matrices, tables, figures, bibliography/BibTeX, TikZ, cross-references, thesis structure, publication workflows and troubleshooting, with strong links into the actual editor/template workflow.
10. **Author/entity pages** — when editorial volume warrants it, expose stable author pages/URLs so `Person` entities can have durable identifiers rather than only a name.

These are roadmap opportunities, not an instruction to create doorway pages. Every indexable page should answer a distinct user intent and provide useful original content or workflow value.

## Search surface acceptance criteria

Hotfix9 passes only if all of the following remain true:

- Initial HTML contains route-specific SEO without requiring client JavaScript.
- Generic OG image is exactly 1200x630 and TeXise-branded.
- Blog detail OG/Twitter imagery uses the article cover when available.
- Article/date/tag/author schema is emitted from real CMS data.
- Unknown routes are real 404s.
- Private routes do not enter the searchable index.
- Query-filtered collection pages do not create duplicate indexable URLs.
- Sitemap, robots and RSS are machine-readable and canonical-origin based.
- SEO/PWA/public runtime surfaces contain no inherited upstream product branding.
- The BF40 guard, SEO node tests, static SaaS audit, release audit and R14.28.20 regression suite all pass.

## Future media improvements

For editorial teams, the next image enhancement should be automatic generation/storage of high-resolution 16:9, 4:3 and 1:1 article-cover derivatives, each with known dimensions and meaningful alt text. The current implementation correctly uses the canonical cover and its real metadata; it does not fabricate missing variants.