feat: improve SEO with keywords and updating descriptions#211
feat: improve SEO with keywords and updating descriptions#211sriramveeraghanta merged 2 commits intomasterfrom
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthroughThis pull request updates documentation across API reference, dev tools, and self-hosting sections. Changes include clarifying delete endpoint descriptions with explicit permanence language and success codes, expanding SEO keywords for improved discoverability, and refining metadata descriptions throughout. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
Note
Due to the large number of review comments, Critical, Major severity comments were prioritized as inline comments.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (9)
docs/self-hosting/govern/environment-variables.md (1)
64-64:⚠️ Potential issue | 🟡 MinorPre-existing typo:
SITE_ADDRES→SITE_ADDRESS.The variable name in the table is missing the trailing
S. Users who copy it verbatim will end up with an unrecognised variable in their Caddy config.✏️ Proposed fix
-| **SITE_ADDRES** | The domain name and port required by Caddy for serving your Plane instance. This determines how Caddy will handle incoming requests. | `localhost:80` | +| **SITE_ADDRESS** | The domain name and port required by Caddy for serving your Plane instance. This determines how Caddy will handle incoming requests. | `localhost:80` |🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/self-hosting/govern/environment-variables.md` at line 64, Fix the typo in the environment variables table: replace the incorrect variable name SITE_ADDRES with SITE_ADDRESS wherever it appears (the table row shown), ensuring the description and example value remain unchanged so users copy the correct variable name for Caddy configuration.docs/self-hosting/methods/install-methods-commercial/kubernetes.md (1)
4-10:⚠️ Potential issue | 🟡 MinorSEO keywords have no effect on this page — it's excluded from all search indexing.
The page sets both
search: false(disables VitePress built-in search) andnoindex, nofollow(prevents external search engine indexing). The new keywords on Line 4 will not be picked up by any search mechanism, making this change a no-op from an SEO perspective.If this page is intentionally hidden from search, the keyword change can be dropped. If it should eventually be discoverable, the
noindex/search: falsedirectives need to be removed first.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/self-hosting/methods/install-methods-commercial/kubernetes.md` around lines 4 - 10, The frontmatter adds a useless "keywords" entry while the page is explicitly excluded from indexing (search: false and head meta name: robots content: noindex, nofollow), so either remove the "keywords:" line entirely to avoid a no-op, or if the page should be discoverable remove the "search: false" and the robots noindex meta under "head" so the keywords can take effect; locate and update the frontmatter keys "keywords", "search", and the "head" meta entry with name: robots accordingly.docs/self-hosting/methods/install-methods-commercial/docker-compose.md (1)
4-10:⚠️ Potential issue | 🟡 MinorSEO keywords have no effect on this
noindexpage.This page explicitly opts out of both external indexing (
noindex, nofollowon Lines 9–10) and VitePress internal search (search: falseon Line 5). Thekeywordsfield added on Line 4 will be ignored by search engines and the internal search engine alike, so this SEO change has no practical impact here.If this page is intentionally excluded from indexing (e.g., it's a duplicate route for the commercial install path), the keywords update can be skipped. If it should be discoverable, the
noindex/search: falseflags should be revisited instead.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/self-hosting/methods/install-methods-commercial/docker-compose.md` around lines 4 - 10, The frontmatter includes a redundant "keywords" field that has no effect because "search: false" and the "head" meta robots entry is set to "noindex, nofollow"; either remove the "keywords" line from the frontmatter if the page should remain excluded, or if the page should be discoverable, change/remove the "search: false" and the "head" meta robots value ("noindex, nofollow") so the "keywords" take effect—update the frontmatter accordingly (edit the "keywords", "search", and "head" entries).docs/api-reference/module/delete-module.md (1)
72-94:⚠️ Potential issue | 🟡 Minor
response.json()called on a body-less 204 response will throw.Both the Python (
print(response.json())) and the JavaScript (await response.json()) snippets attempt to parse a response body that does not exist for a 204 No Content. Python raisesjson.JSONDecodeError; the Fetch API rejects the promise with aSyntaxError.🛠️ Proposed fix
-print(response.json()) +print(response.status_code) # 204 No Content-const data = await response.json(); +// 204 No Content — no body to parse +console.log(response.status); // 204🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/api-reference/module/delete-module.md` around lines 72 - 94, The examples call response.json() on a 204 No Content response which will throw; update both samples to first check for no-content before parsing: in the Python snippet (the requests.delete call and subsequent print(response.json())) inspect response.status_code (or response.content) and only call response.json() when status_code != 204 (otherwise print a success message or response.status_code); in the JavaScript snippet (the fetch call where you await response.json() into data) check response.status === 204 (or use response.headers.get('content-length')/response.ok) and avoid calling response.json() for 204 responses, handling them with a suitable success message instead.docs/api-reference/link/add-link.md (1)
135-147:⚠️ Potential issue | 🟡 MinorResponse example shows project fields instead of link fields.
The 201 body contains
name,identifier, anddescription— fields from a project object. Per the Link object definition in the overview, the response should containtitle,url,metadata,project,workspace,issue, etc.📄 Proposed fix
<ResponsePanel status="201"> ```json { - "id": "project-uuid", - "name": "Project Name", - "identifier": "PROJ", - "description": "Project description", - "created_at": "2024-01-01T00:00:00Z" + "id": "662dd6b2-2b01-4315-955f-480eb51baa14", + "created_at": "2024-01-01T00:00:00Z", + "updated_at": "2024-01-01T00:00:00Z", + "title": "example-title", + "url": "https://example.com", + "metadata": {}, + "created_by": "16c61a3a-512a-48ac-b0be-b6b46fe6f430", + "updated_by": "16c61a3a-512a-48ac-b0be-b6b46fe6f430", + "project": "4af68566-94a4-4eb3-94aa-50dc9427067b", + "workspace": "cd4ab5a2-1a5f-4516-a6c6-8da1a9fa5be4", + "issue": "e1c25c66-5bb8-465e-a818-92a483423443" }</details> <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against the current code and only fix it if needed.
In
@docs/api-reference/link/add-link.mdaround lines 135 - 147, The response
example inside ResponsePanel currently shows a Project object (fields like name,
identifier, description) instead of a Link object; update the JSON example in
add-link.md (the ResponsePanel block returning 201) to match the Link schema by
replacing project fields with Link fields such as id, created_at, updated_at,
title, url, metadata, created_by, updated_by, project, workspace, and issue (use
realistic UUIDs and timestamps as in the proposed fix) so the example aligns
with the Link object definition referenced in the overview.</details> </blockquote></details> <details> <summary>docs/api-reference/link/get-link-detail.md (1)</summary><blockquote> `106-117`: _⚠️ Potential issue_ | _🟡 Minor_ **Same copy-paste issue as `add-link.md` — response body shows project fields instead of link fields.** `name`, `identifier`, and `description` are project attributes. The GET response for a link should mirror the Link object schema (see `overview.md`). <details> <summary>📄 Proposed fix</summary> ```diff <ResponsePanel status="200"> ```json { - "id": "project-uuid", - "name": "Project Name", - "identifier": "PROJ", - "description": "Project description", - "created_at": "2024-01-01T00:00:00Z" + "id": "662dd6b2-2b01-4315-955f-480eb51baa14", + "created_at": "2024-01-01T00:00:00Z", + "updated_at": "2024-01-01T00:00:00Z", + "title": "Plane Website", + "url": "https://plane.so", + "metadata": {}, + "created_by": "16c61a3a-512a-48ac-b0be-b6b46fe6f430", + "updated_by": "16c61a3a-512a-48ac-b0be-b6b46fe6f430", + "project": "4af68566-94a4-4eb3-94aa-50dc9427067b", + "workspace": "cd4ab5a2-1a5f-4516-a6c6-8da1a9fa5be4", + "issue": "e1c25c66-5bb8-465e-a818-92a483423443" }</details> <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against the current code and only fix it if needed.
In
@docs/api-reference/link/get-link-detail.mdaround lines 106 - 117, The
response example in get-link-detail.md mistakenly shows project fields (name,
identifier, description); replace that JSON with a Link object example matching
the Link schema used in overview.md: include id, created_at, updated_at, title,
url, metadata (object), created_by, updated_by, project, workspace, and issue
with realistic UUIDs/timestamps so the GET /link response mirrors the Link
object structure rather than project attributes.</details> </blockquote></details> <details> <summary>docs/api-reference/link/delete-link.md (1)</summary><blockquote> `80-100`: _⚠️ Potential issue_ | _🟡 Minor_ **Same `.json()`-on-204 issue as in `delete-teamspace.md`.** Both the Python (`print(response.json())`) and JavaScript (`const data = await response.json()`) samples will throw on the empty 204 body. See the fix pattern proposed in `delete-teamspace.md`. <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against the current code and only fix it if needed.
In
@docs/api-reference/link/delete-link.mdaround lines 80 - 100, The examples
call response.json() unguarded which will throw on a 204 No Content response;
update both the Python example (print(response.json())) and the JavaScript
example (const data = await response.json()) to first check the response status
or existence of a body (e.g., response.status === 204 or check
Content-Length/response.text() length) and only parse JSON when there is
content, otherwise handle the empty 204 case appropriately (e.g., print a
success message or set data to null).</details> </blockquote></details> <details> <summary>docs/api-reference/teamspace/list-teamspace-projects.md (1)</summary><blockquote> `53-55`: _⚠️ Potential issue_ | _🟡 Minor_ **Duplicate `name="limit"` — second query parameter should be `name="offset"`.** The second `<ApiParam>` documents the skip/pagination offset but reuses `name="limit"`, making both parameters appear identical in the rendered docs. <details> <summary>🐛 Proposed fix</summary> ```diff -<ApiParam name="limit" type="number"> +<ApiParam name="offset" type="number"> Number of results to skip for pagination.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/api-reference/teamspace/list-teamspace-projects.md` around lines 53 - 55, The second <ApiParam> entry currently reuses name="limit" causing duplicate parameters; update that second ApiParam to use name="offset" (the pagination skip/offset parameter) and ensure its description remains "Number of results to skip for pagination." so the docs render distinct limit and offset params; look for the duplicated <ApiParam name="limit"> block in the list-teamspace-projects doc and change its name attribute to "offset".docs/api-reference/teamspace/delete-teamspace.md (1)
68-88:⚠️ Potential issue | 🟡 MinorCode samples call
.json()on a 204 No Content response — this will throw.The updated description now explicitly advertises
Returns 204 on success, making it more likely that readers will test these snippets verbatim. A 204 response has no body; bothresponse.json()(Pythonrequests) andresponse.json()(Fetch API) raise/reject when called against an empty body.🐛 Proposed fix for both samples
response = requests.delete( "https://api.plane.so/api/v1/workspaces/my-workspace/teamspaces/{teamspace_id}/", headers={"X-API-Key": "your-api-key"} ) -print(response.json()) +# 204 No Content — no response body +print(response.status_code) # 204const response = await fetch( "https://api.plane.so/api/v1/workspaces/my-workspace/teamspaces/{teamspace_id}/", { method: "DELETE", headers: { "X-API-Key": "your-api-key" } } ); -const data = await response.json(); +// 204 No Content — no response body +console.log(response.status); // 204The same pattern appears in the Python/JS samples of other delete-endpoint docs updated in this PR (
delete-link.md,delete-project.md).🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/api-reference/teamspace/delete-teamspace.md` around lines 68 - 88, The samples call response.json() unconditionally which will throw on a 204 No Content; update both snippets (the Python requests.delete call and the JS fetch call) to check the response status (e.g., if response.status_code == 204 / if (response.status === 204)) or inspect the body before calling response.json(), and only parse JSON when there is content—otherwise handle the success case without parsing (e.g., print a success message or return early).
5aeb14d to
3ab36ad
Compare
Description
Type of Change
Summary by CodeRabbit