Review rejected SEO audit suggestions

[LukasWallrich]

Review of rejected or materially revised audit suggestions

@Keegan-Vaz — please double-check this triage, especially the hosting and content-priority calls.

The attached SEO audit was reviewed against the current main branch and live HTML on 25 August 2026. Confirmed or corrected findings were opened separately:

• #861 — lazy-load the search index.
• #865 — conditionally load Mermaid/Highlight.js.
• #860 — repair heading hierarchy.
• #866 — replace the /glossary/ stub.
• #864 — improve meta-description generation.
• #868 — make resource browsing incremental and crawlable.
• #862 — enrich/link author profiles.
• #863 — add LearningResource structured data.
• #867 — fix glossary breadcrumbs.
• #859 — make sitemap lastmod accurate.
• #869 — fix image alt text and dimensions.

Suggestions not adopted as written

1. “1,490 curated resources are 136 pagination clicks deep.” This did not reproduce against the current deployment. /resources/ is the canonical landing page, /resources/page/2/ returns 404, and the current page is a roughly 3.8 MB headless/client-filtered document. The underlying performance and crawlability concern is real, so Make curated-resource browsing incremental and crawlable #868 addresses that corrected problem rather than implementing the audit’s stale URL/depth model.

2. “Truncate every meta description at ~155–160 characters.” Google documents no fixed meta-description limit and truncates snippets according to device width. Generate accurate, unique meta descriptions #864 retains the useful parts—accurate, unique, page-specific descriptions and word-boundary handling—without treating 155–160 characters as an SEO rule.

3. “Add security headers by moving off GitHub Pages.” The headers are absent, but GitHub Pages is the current hosting constraint and the audit provides no evidence that a migration is justified by the SEO findings alone. This can be revisited if FORRT moves behind Cloudflare/Netlify or needs a broader security-hardening project; it is not opened as an issue now.

4. “Fix glossary thin content by increasing word counts.” No padding is recommended. Google explicitly warns against writing to a target word count, and the glossary already provides definitions, references, related terms, translations, and reviewer attribution. The higher-value missing connection—linking contributors to verified author entities—is covered by Enrich author profiles and link glossary contributors #862.

5. Generic og:image on glossary pages. A shared, valid social preview image is not inherently a defect, and the audit did not demonstrate a broken preview or material user impact. It is lower priority than the confirmed template issues.

6. Duplicate preconnects. The duplication is a small, localized performance cleanup (the chatbot partial repeats the Google Fonts preconnects), but it is not material enough to warrant a separate issue alongside the larger payload fixes. It can be removed opportunistically while touching the head partial.

7. Case-sensitive routing and double-slash paths. These are edge-case URL behaviours with no demonstrated high-value traffic or safe server-side redirect mechanism on the current GitHub Pages setup. Avoid adding redirect hacks that could affect existing URLs.

8. Truncated curated-resource slugs. Changing existing slugs risks breaking backlinks and the audit itself calls this cosmetic. Preserve the URLs; address naming only for newly generated content if desired.

9. Create a Wikidata item for FORRT. This is an optional entity/editorial project, not a demonstrated technical defect. It needs an ownership and verification decision before becoming engineering work.

10. Add llms.txt. This is optional and not a Google requirement; the audit correctly notes that a useful file for this corpus would require ongoing editorial curation. No issue is warranted at present.

11. Remove all short glossary/resource pages based on word-count thresholds. The content is intentionally dictionary/resource-style and includes scholarly attribution. No evidence was provided that length alone is causing a meaningful indexing problem, so no deletion or padding work is proposed.

[Keegan-Vaz]

Four things I'd like to correct or re-scope. I rechecked everything below against the live site on 26 August 2026.

1. The check looked at a different page

/resources/ and /curated_resources/ are two different pages. The audit measured /curated_resources/, which is still there:

/curated_resources/ 200
/curated_resources/page/2/ 200
/curated_resources/page/135/ 200 → links only to 134 and 136
/resources/ 200 3.86 MB
/resources/page/2/ 404

So the 136-page chain exists. Two problems, and they make each other worse:

• /resources/ is what visitors get, and it has no crawlable links. The 3.86 MB page builds its links in the browser, so the served HTML contains zero links to individual resource pages. Site navigation points here.
• /curated_resources/ is the only page that does link to them, and it's 136 clicks deep. Each of those 136 pages also says canonical → /curated_resources/, and none of them are in the sitemap.

Net effect: the 1,490 resource pages can only be found through the sitemap. Nothing on the site links to most of them.

Ask: update #868 so it covers the /curated_resources/ pagination as well as the big /resources/ page. I don't think it needs a separate issue.

2. The audit's thin-content section says, word for word: "Don't pad the definitions — that would damage what makes them good." It never suggested deleting pages or hitting a word count. The "defer to real indexation data" caveat you mention is the audit's own caveat.

What it actually suggested was adding links around the definition, not text inside it:

1. Show related terms as a real linked cluster.
2. Link the reviewer names to author pages. ← only this one is tracked (Enrich author profiles and link glossary contributors #862)
3. Show the term's translations inline on the page.

Items 1 and 3 aren't in any issue. The data for both already exists — partials/functions/glossary_translations.html already builds the translation groups for hreflang, so rendering them is mostly a display change.

Ask: add these two to #862, or open one small issue for glossary page linking.

3. The og:image call is right about the policy, but the tag itself is broken

Agreed that sharing one image across pages isn't a defect. The problem is what's in the tag:

og:image https://forrt.org/img/FORRTbanner.webp
og:image:width 4000
og:image:height 2250

It's a WebP file, and X and LinkedIn don't render WebP previews. There are also no twitter:card tags anywhere on the site. So when someone shares a glossary or resource link on those platforms, they get a bare link with no preview image at all. #852 flagged this in its own "Not addressed" list.

Ask: small issue — generate a 1200×630 PNG or JPG as the default, and add the twitter:card tags.

4. //glossary/ returns 200. Agreed there's no safe fix for case-sensitive URLs on GitHub Pages. But the double-slash version currently serves the stub, which has no self-referential canonical. Once Replace the broken /glossary/ stub with a real hub #866 turns /glossary/ into a real hub, //glossary/ becomes a duplicate of a page we care about. One acceptance criterion in Replace the broken /glossary/ stub with a real hub #866 handles it.