fix(docs): correct typographical errors in multiple blog files

apps/site/pages/en/blog/announcements/v20-release-announce.md

@@ -157,7 +157,7 @@ node --experimental-sea-config sea-config.json
 
 This blob can now be injected into the binary.
 
-This change was made to allow the the possibility of embedding multiple co-existing resources into the SEA (Single Executable Apps) which opens up new use cases.
+This change was made to allow the possibility of embedding multiple co-existing resources into the SEA (Single Executable Apps) which opens up new use cases.
 
 Contributed by Joyee Cheung in [#47125](https://github.com/nodejs/node/pull/47125)
 

apps/site/pages/en/blog/release/v12.17.0.md

@@ -266,7 +266,7 @@ consumption.
 #### Increase of the default server headers timeout
 
 The default value of `server.headersTimeout` for `http` and `https` servers was
-increased from `40000` to `60000` (60 seconds). This to accomodate for systems
+increased from `40000` to `60000` (60 seconds). This to accommodate for systems
 like AWS ELB that have a timeout of 60 seconds.
 
 Contributed by Tim Costa - [#30071](https://github.com/nodejs/node/pull/30071).

apps/site/pages/en/blog/release/v18.14.0.md

@@ -38,7 +38,7 @@ breaking changes.
 
 ##### Login
 
-> Explanation: the default `auth-type` has changed and users can opt back into the old behavior with `npm config set auth-type=legacy`. `login` and `adduser` have also been seperated making each command more closely match it's name instead of being aliases for each other.
+> Explanation: the default `auth-type` has changed and users can opt back into the old behavior with `npm config set auth-type=legacy`. `login` and `adduser` have also been separated making each command more closely match it's name instead of being aliases for each other.
 
 - Legacy auth types `sso`, `saml` & `legacy` have been consolidated into `"legacy"`.
 - `auth-type` defaults to `"web"`

apps/site/pages/en/blog/release/v23.0.0.md

@@ -22,7 +22,7 @@ According to the release schedule, Node.js 23 will remain the ‘Current’ rele
 
 Support for loading native ES modules using `require()` had been available on v20.x and v22.x under the command line flag `--experimental-require-module`. In v23.x, this feature is now enabled by default. This feature is still experimental, and we are looking for user feedback to make more final tweaks before fully stabilizing it. For this reason, on v23.x, when the Node.js instance encounters a native ES module in `require()` for the first time, it will emit an experimental warning.
 
-If there happens to be any regressions caused by this feature, users can report it to the Node.js issue tracker. Meanwhile this feature can also be disabled using `--no-experimental-require-module` as a workaround. We expect to test this feature using v23.x, find out any potential regressions and make adjustments accordingly, before backporting the unflagging to v22.x. This will likely happen in a later semver-minor release after the the LTS promotion at the end of October.
+If there happens to be any regressions caused by this feature, users can report it to the Node.js issue tracker. Meanwhile this feature can also be disabled using `--no-experimental-require-module` as a workaround. We expect to test this feature using v23.x, find out any potential regressions and make adjustments accordingly, before backporting the unflagging to v22.x. This will likely happen in a later semver-minor release after the LTS promotion at the end of October.
 
 With this feature enabled, Node.js will no longer throw `ERR_REQUIRE_ESM` if `require()` is used to load a ES module. It can, however, throw `ERR_REQUIRE_ASYNC_MODULE` if the ES module being loaded or its dependencies contain top-level `await`. When the ES module is loaded successfully by `require()`, the returned object will be a ES module namespace object similar to what's returned by `import()`, and can be checked using `util.isModuleNamespaceObject()`.
 

apps/site/pages/en/blog/vulnerability/july-2022-security-releases.md

@@ -146,7 +146,7 @@ With respect to the vulnerabilities in the OpenSSL Security releases of Jul 5th
 
 - Node.js is affected by **one** MODERATE vulnerability on Windows 32-Bit x86.
 
-The security release will be delayed so that we can incorporate the the updated OpenSSL versions. We
+The security release will be delayed so that we can incorporate the updated OpenSSL versions. We
 will post another update once we have an updated target for the release date.
 
 ### Analysis