seo: link plugin logos to group page + fix dead EE redirect rules#4969
Open
vfanucci wants to merge 2 commits into
Open
seo: link plugin logos to group page + fix dead EE redirect rules#4969vfanucci wants to merge 2 commits into
vfanucci wants to merge 2 commits into
Conversation
The plugin logo carousels (PluginsBlock, EveryPlugin, PluginsBox) built links
as `/plugins/${artifactId}/${name}`. For ~82 plugins the `/${name}` subgroup
URL does not exist (404) and the middleware catch-all 301-redirects it to the
group page `/plugins/${artifactId}`. Screaming Frog flagged ~1,200 internal
links pointing to these redirects, concentrated on /use-cases/* and /features/*.
Since these are decorative logo links, point them straight at the plugin group
page (always 200) to remove the 404 -> 301 hop.
Also reorder src/contents/redirects/plugins.yml: the middleware applies the
FIRST matching rule (notFoundRedirect -> allEntries[0]), so the catch-all
`/plugins/plugin-([^/]+).*` placed before the specific EE batch/cloudrun rules
made those rules dead. Moved the catch-all to the end and fixed a leading-space
typo in the plugin-azure rule that prevented it from ever matching.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Contributor
☁️ Cloudflare Worker Preview Deployed!🔗 https://ks-seo-fix-plugin-redirect-links-docs.kestra-io.workers.dev ## 🔦 Lighthouse Benchmark
Scores (0–100, higher is better)
Core Web Vitals (lower is better)
Legend🟢 improved · 🔻 regressed · (blank) no significant change |
Verified live: the EE rule targets (e.g. /plugins/plugin-ee-aws/io.kestra. plugin.ee.aws.runner.batch) themselves 301 to a subgroup URL. Now that the catch-all is reordered last, these rules fire again — so point them straight at the final 200 URL (adding the aws-batch-task-runner / azure-runner / google-cloud-task-runner subgroup) to keep it a single 301 instead of a chain. Kubernetes already resolves 200 directly and is unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
Technical SEO audit (Screaming Frog, 2026-06-15): ~1,207 internal links point to URLs that return a 301, concentrated on
/use-cases/*and/features/*. Source = the plugin logo carousels.Root cause
The three logo components build links as
/plugins/${artifactId}/${name}. For ~82 plugins the/${name}subgroup URL does not exist (404) and the middleware (notFoundRedirect) 301-redirects it to the group page/plugins/${artifactId}. Each affected logo is a wasted 404→301 hop (×105 for the 4 most frequent: airtable-record, argo-cd-apps, ansible-cli, airflow-dags).Note: 385
/plugins/plugin-X/namesubgroup pages do exist (200). Since these are decorative logo links, all logos now point at the group page (always 200) — the semantically correct destination for a logo, with no redirect. If the team prefers to keep deep-links for the 385 valid ones, thename → slugmapping should instead be made reliable in the plugin metadata.Changes
PluginsBlock.astro,EveryPlugin.astro,PluginsBox.astro: logo link →/plugins/${artifactId}.src/contents/redirects/plugins.yml: the middleware applies the first matching rule (allEntries[0]). The catch-all/plugins/plugin-([^/]+).*was placed before the specific EE rules (aws/azure/gcp/kubernetes runner), so those never fired. Moved the catch-all to the end, fixed a leading-space typo in theplugin-azurerule, and pointed the EE rules directly at their final 200 URL (adding theaws-batch-task-runner/azure-runner/google-cloud-task-runnersubgroup) so reactivating them is a single 301, not a chain.Verified
/plugins/plugin-{airtable,argocd,ansible,airflow,trello,jira,microsoft-fabric}confirmed 200 in the crawl.plugins.ymlvalidated (YAML parses, catch-all last, no leading-space rule).🤖 Generated with Claude Code