Skip to content

SEO Enhancements: - #361

Draft
stumbo wants to merge 4 commits into
mainfrom
bs42_SEO_Optimization_Phase_1
Draft

stumbo wants to merge 4 commits into
mainfrom
bs42_SEO_Optimization_Phase_1

Conversation

@stumbo

@stumbo stumbo commented Nov 11, 2026

Copy link
Copy Markdown
Member

AI review of website identifies several areas where we could make changes to improve SEO. The work is broken into multiple phases.

New file

  • static/images/og-default.png — a 1200×630 default share image (white Interlisp logo + "The Medley Interlisp Project" / "interlisp.org" on the site's #30638e primary color with a subtle gradient). Generated with PIL; 43 KB. config/_default/params.yaml
  • Replaced the commented-out images line with a live images: [images/og-default.png] default.
  • Added fediverse_creator: "@interlisp@fosstodon.org". layouts/_partials/hooks/head-end.html (the head injection point)
  • Emits og:image:alt and twitter:image:alt, derived from the page title (falling back to site title), only when an image is present.
  • Emits , with a page-level fediverse_creator frontmatter override. archetypes/default.md — added commented images: and fediverse_creator: examples for new pages. README.md — new "Social Share Images and Metadata" subsection (plus TOC entry) covering the default image, per-page overrides, alt text, Mastodon attribution, and the Bluesky/Mastodon Open-Graph-only behavior.

New file
- static/images/og-default.png — a 1200×630 default share image (white Interlisp logo + "The Medley Interlisp Project" / "interlisp.org" on the site's #30638e primary color with a subtle gradient). Generated with PIL; 43 KB.
config/_default/params.yaml
- Replaced the commented-out images line with a live images: [images/og-default.png] default.
- Added fediverse_creator: "@Interlisp@fosstodon.org".
layouts/_partials/hooks/head-end.html (the head injection point)
- Emits og:image:alt and twitter:image:alt, derived from the page title (falling back to site title), only when an image is present.
- Emits <meta name="fediverse:creator">, with a page-level fediverse_creator frontmatter override.
archetypes/default.md — added commented images: and fediverse_creator: examples for new pages.
README.md — new "Social Share Images and Metadata" subsection (plus TOC entry) covering the default image, per-page overrides, alt text, Mastodon attribution, and the Bluesky/Mastodon Open-Graph-only behavior.
@stumbo stumbo self-assigned this Nov 11, 2026
@interlisp-staging-bot

Copy link
Copy Markdown

Staging preview for this pull request is available at https://interlisp.org/Interlisp.staging/pr-361/

@pamoroso

Copy link
Copy Markdown
Member

The staging site looks good with no apparent user-facing issues.

JSON-LD for non-bibliography pages

Four new partials (layouts/_partials/), all following the existing bibliography-json-ld.html output convention (printf + jsonify + safeHTML)

- layouts/_partials/hooks/head-end.html — calls the four new partials (each self-guards, so no duplication with the bibliography schema).
- content/en/project/faqs.md — added schema: faq.
- README.md — new "Structured Data (JSON-LD)" section + TOC entry (schema table, auto-derived Article metadata, FAQ opt-in, validation pointer).
- docs/SEO_IMPROVEMENT_PLAN.md — checked off 1.2 tasks, added implementation notes, updated the baseline/gap analysis/success metrics, and logged a change-log entry.# Please enter the commit message for your changes. Lines starting
@interlisp-staging-bot

Copy link
Copy Markdown

Staging preview for this pull request is available at https://interlisp.org/Interlisp.staging/pr-361/

@pamoroso

Copy link
Copy Markdown
Member

Still looking good at commit 500e031.

This update adds a metadata description for each page.  This description
is folded into the jsonld now being generated and attached to each page
for seach engines.  In addition, docsy uses the description and adds it
at the top of each page.  I've left that functionality intact.  I
haven't reviewed each page to validate that the description and the page
text flow together appropriately...
@interlisp-staging-bot

Copy link
Copy Markdown

Staging preview for this pull request is available at https://interlisp.org/Interlisp.staging/pr-361/

@pamoroso

Copy link
Copy Markdown
Member

Still looking good at commit 6552c4c.

@interlisp-staging-bot

Copy link
Copy Markdown

Staging preview for this pull request is available at https://interlisp.org/Interlisp.staging/pr-361/

@pamoroso

Copy link
Copy Markdown
Member

Still looking good at commit c687993.

Comment thread archetypes/default.md
date: {{ .Date }}
draft: true
# Optional: override the default social share image (Open Graph / Twitter Card).
# Place the file under static/ and reference it site-relative, e.g.:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does this mean? "Optional"? FOr what? For whom?
What is an Open Graph / TWitter Card?

Is this just a comment?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Open Graph and Twitter Card -- these are tags that get inserted into the pages html that are supposed to help improve the appearance of the page IF it is shared via Twitter/X (Twitter Card), LinkedIn, BlueSky (Open Graph).

The comments allude to being able to redefine default values - likely of little interest, I wasn't sure I wanted to delete them yet. The potential interplay with params.yml isn't clear to me and I left these here until I better understand it.

# Default social share image (Open Graph / Twitter Card).
# The first entry is used when a page does not set its own `images` front matter.
# Recommended size: 1200x630 px. Served from static/, so the path is site-relative.
images:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought we were not going to support twitter anyway

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We aren't -- one of the updates is to add support for Twitter/X users that share our pages. While this may be a tails case, I thought the overhead was small. The goal is that when an Interlisp.org site is shared it that instead of just a url, you get an image, which should look like this:

image

There is supposed to be a way of testing -- one of the reasons I wanted to stage this, so I can give the test tools real live websites and see what really happens.

@@ -1,5 +1,6 @@
---
title: Interlisp Bibliography Intake Guide
description: "Not sure whether a document belongs in the Interlisp Bibliography? This guide explains the collection's scope, how to submit an item, and what to include."

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where else could it go? Who isn't sure?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a description of the Intake Guide page - whose explicit purpose is to help answer those questions. The goal of the description is to help provide context for search engines that index our site. I believe this description fits in with the role of the Intake Guide. This wasn't meant as a comment for someone editing the website.

Comment thread archetypes/default.md
title: "{{ replace .Name "-" " " | title }}"
date: {{ .Date }}
draft: true
# Optional: override the default social share image (Open Graph / Twitter Card).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the AI policy should state something like "PRs that include either text or code that was generated by AI or LLM should state clearly and plainly at the top that they were AI generated. No PR that was AI generated should be approved by anyone without explicit accomodation for review for slop. "

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a draft PR because I'm not comfortable with the content yet - but, by pushing it and creating a draft PR I can leverage the staging site and see and kick the tires. That said, comments are welcome, it will help me focus my efforts and test my assumptions.

As far as AI policy - you're welcome to use my draft PR to poke at what it should be. But, I suspect the audience is much more limited than we need to define the actual policy.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As an aside, one of the things I try to do when using AI is have it create an implementation plan. Something I can review prior to doing any actual work, modify or ask clarifying questions. And, as I proceed with AI assisted implementation, I have it update the document with the completed work and any findings. My selfish goal is to keep enough of a record so when I put things aside for multiple weeks I can quickly reset my context -- and the AI's context.

I currently keep those local. I've wondered if it might be worthwhile adding them to the repo. For instance all the work in this PR represents one phase of a plan. There is additional work that can be done to improve SEO, but the effort vs payoff is less clear. This is all low effort, low risk work that ideally improves the site.

That would help provide more context to the work - allow others to comment or provide direction and create a history of how we've used AI (hopefully for better).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Idea: for AI work, instead of putting into the repository the "implementation plan" (or even just the sequence of input "prompts"), requiring that information to be documented in the PR might be sufficient, and avoid repo-clutter.
In any case, the PR must describe how AI was used, e.g.:

  1. AI just for debugging handwritten code
  2. AI for analysis, but no AI code in final deliverable
  3. Full AI implementation from prompts
  4. AI translation of (external) existing code from another programming language
  5. etc.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really want to allow merging AI content to the core Medley repos? As this article notes from the experience of open source projects, the only effective AI policy is totally restrictive, as allowing any form of AI (disclosure, human review, and so on) inevitably leads to AI contributions dominating the project and fundamentally changing the nature of the system.

I also think allowing AI code in Medley is not a good fit for a history project, for the reasons I explained in issue Interlisp/medley#2612. The reason I suggest such caution is that, while a permissive policy is largely irreversible, a restrictive one has essentially no drawbacks.

@stumbo stumbo Nov 13, 2026 •

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@MattHeffron I think just listing the input prompts is oversimplifying the interaction. Currently, I've been experimenting with OpenCode as a tool to wrap my AI interactions, Big Pickle and Claude as models. I also have a couple plugins and one MCP server to assist the AI. One provides rules that limit what the AI can do or access, one helps clean the context and limit token usage and the MCP server uses mermaid for diagramming. This piece of work started with one simple prompt:

Review Interlisp.github.io. It is a Hugo website. I'd like to put together a list of task to improve Search Engine Optimization.

Followed by:

Let's write out the plan so we can tract progress against it. Place the plan in the docs folder.

I gave those prompts to Claude. I then switched to Big Pickle and asked it:

Review the SEO_Improvement_Plan in the docs folder. Validate that the plan is correct.

Which yielded a few points where it pointed out issues in the plan - mostly things that already existed that Claude neglected to catch.

Yes, revise the Specification.

The resulting plan has four phases: Phase 1 (social share images, JSON-LD, meta descriptions, robots.txt), Phase 2 (content/keyword strategy), Phase 3 (technical / Core Web Vitals), and Phase 4 (monitoring).

This PR is all centered around Phase 1 - the social share is the most iffy part of this PR, is it really necessary? My social media usage is minimal so I am a poor judge. The JSON-LD and meta descriptions are important, I want to do as much as I can to make the website more usable in searching (this ties directly to my long term interest of AI assisted search) and the robots.txt is a minor cleanup issue.

What I will include in the PR once I move it out of draft is a much more verbose description of the changes. I'm fine with specifying that this work was greatly assisted/driven by AI. I also know that in the end, the responsibility for the code falls on my shoulders.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants