diff --git a/src/content/contributor-docs/en/steward_guidelines.mdx b/src/content/contributor-docs/en/steward_guidelines.mdx
index 994f5999e5..3d07a96683 100644
--- a/src/content/contributor-docs/en/steward_guidelines.mdx
+++ b/src/content/contributor-docs/en/steward_guidelines.mdx
@@ -112,7 +112,7 @@ Bug report issues should use the "Found a bug" issue template. The following wor
      * Otherwise, leave a comment about where the bug report should be filed (with a direct link provided) and close the issue.
    * The first step in reviewing a bug report is to see if enough information is provided for a bug replication, and if so, attempt to replicate the bug as described.
 2. If the bug can be replicated:
-   * Some discussion may be required to determine the best way to fix a particular bug. Sometimes, it may be straightforward; sometimes, it may be tricky. Please refer to [p5.js' design principles](../contributor_guidelines.md#software-design-principles) when making this decision on a case-by-case basis.
+   * Some discussion may be required to determine the best way to fix a particular bug. Sometimes, it may be straightforward; sometimes, it may be tricky. Please refer to [p5.js' design principles](../contributor_guidelines/#software-design-principles) when making this decision on a case-by-case basis.
    * If the issue author indicated in the issue they are willing to contribute a fix:
      * Approve the issue for fixing by the issue author by leaving a comment and assigning them to the issue. Use the cog button on the right side next to "Assignee".
    * If the issue author does not wish to contribute a fix:
@@ -137,7 +137,7 @@ Feature request issues should use the "New Feature Request" issue template. The
    * If a feature request does not have the "Increasing Access" field sufficiently filled out, you can ask the issue author how the feature increases access.
    * The access statement of a feature can be provided by a different member of the community, including the issue reviewers.
 2. The new feature request can be assessed for inclusion based on the following criteria.
-   * Does the feature fit into the project scope and [design principles](../contributor_guidelines.md#software-design-principles) of p5.js?
+   * Does the feature fit into the project scope and [design principles](../contributor_guidelines/#software-design-principles) of p5.js?
      * For example, a request to add a new drawing primitive shape may be considered, but a request to adopt a browser-based IOT protocol will likely be out of scope.
      * Overall, the scope of p5.js should be relatively narrow in order to avoid excessive bloat from rarely used features.
      * If a feature does not fit into the scope of p5.js, suggest that the issue author implement the feature as an addon library.
@@ -235,7 +235,7 @@ Dependabot PRs are usually only visible to repo admins so if this does not apply
 
 ## Build process
 
-This section will not cover the general build setup nor commands but rather details about what's happening behind the scenes. Please see the [contributor’s guidelines](../contributor_guidelines.md#working-on-p5js-codebase) for more detailed build info.
+This section will not cover the general build setup nor commands but rather details about what's happening behind the scenes. Please see the [contributor’s guidelines](../contributor_guidelines/#working-on-p5js-codebase) for more detailed build info.
 
 The Gruntfile.js file contains the main build definitions for p5.js. Among the different tools used to build the library and documentation includes but not limited to Grunt, Browserify, YUIDoc, ESLint, Babel, Uglify, and Mocha. It may be helpful for us to start with the `default` task and work backward from there. It may be helpful at this point to open up the Gruntfile.js document while going through the explainer below.