diff --git a/docs/guides/Custom-HTML-parser.md b/docs/guides/Custom-HTML-parser.md
index 2a3a19c70..6de1ab1d8 100644
--- a/docs/guides/Custom-HTML-parser.md
+++ b/docs/guides/Custom-HTML-parser.md
@@ -13,7 +13,7 @@ This is useful for:
 - cases where component recognition should not depend on browser DOM nodes
 
 ::: warning
-This guide requires GrapesJS v0.22.17 or higher
+This guide requires GrapesJS v0.23.1 or higher
 :::
 
 [[toc]]
diff --git a/docs/modules/Components.md b/docs/modules/Components.md
index 4ae1a810d..3b420281c 100644
--- a/docs/modules/Components.md
+++ b/docs/modules/Components.md
@@ -93,7 +93,7 @@ As we mentioned before, when you pass an HTML string as a component to the edito
 
 <img :src="$withBase('/component-type-stack.svg')" class="img-ctr">
 
-When you use a custom HTML code parser via `Parser.parserCode`, component recognition can also rely on `isParsedNode`, which receives the normalized parsed node instead of a DOM element.
+Component recognition can also rely on `isParsedNode`, which receives the normalized parsed node instead of a DOM element. If a component defines both `isParsedNode` and `isComponent`, `isParsedNode` is preferred.
 
 ::: tip
 If you're importing big string chunks of HTML code you might want to improve the performances by skipping the parsing and the component recognition steps by passing directly Component Definition objects or using the JSX syntax.
@@ -256,6 +256,10 @@ To understand better how Traits work you should read its [dedicated page](Traits
 
 ### isComponent
 
+::: warning
+From `v0.23.1`, prefer `isParsedNode` over `isComponent` for new component types. It is the recommended API and avoids relying on DOM-specific behavior during component recognition.
+:::
+
 Let's see in detail what we have done so far. The first thing to notice is the `isComponent` function, we have already mentioned its usage in [this](#component-recognition-and-component-type-stack) section and we need it to make the editor understand `<input>` during the component recognition step.
 It receives only the `el` argument, which is the parsed HTMLElement node and expects a truthy value in case the element satisfies your logic condition. So, if we add this HTML string as component
 
@@ -343,7 +347,7 @@ If you define the Component Type without using `isComponent`, the only way for t
 
 ### isParsedNode
 
-If your HTML is parsed through a custom code parser, you can avoid DOM dependencies completely by using `isParsedNode`.
+If you want to avoid DOM dependencies during component recognition, you can use `isParsedNode`.
 
 ```js
 editor.Components.addType('my-input-type', {
@@ -359,9 +363,9 @@ editor.Components.addType('my-input-type', {
 ```
 
 The method receives a normalized parsed node and can return the same kind of values accepted by `isComponent`.
-If both `isParsedNode` and `isComponent` are provided, `isParsedNode` has priority while `parserCode` is active.
+If both `isParsedNode` and `isComponent` are provided, `isParsedNode` always has priority.
 
-Existing `isComponent` definitions continue to work in headless parsing too. In that case GrapesJS provides a read-only synthetic element with common DOM-like properties such as `tagName`, `childNodes`, `children`, `getAttribute`, and `textContent`.
+Existing `isComponent` definitions continue to work in headless parsing too. When a custom HTML code parser is active, GrapesJS provides a read-only synthetic element with common DOM-like properties such as `tagName`, `childNodes`, `children`, `getAttribute`, and `textContent`.
 
 If one of your legacy checks needs extra helpers, extend the synthetic element globally:
 
diff --git a/packages/core/package.json b/packages/core/package.json
index 6ecf19a43..da3835a0a 100644
--- a/packages/core/package.json
+++ b/packages/core/package.json
@@ -1,7 +1,7 @@
 {
   "name": "grapesjs",
   "description": "Free and Open Source Web Builder Framework",
-  "version": "0.22.16",
+  "version": "0.23.0",
   "author": "Artur Arseniev",
   "license": "BSD-3-Clause",
   "homepage": "http://grapesjs.com",