Onboarding EVM devs using SEO and GEO results#1377
Conversation
|
Nice 👍🏼 Will give it a review later today |
LUKSOAgent
left a comment
LUKSOAgent
left a comment
There was a problem hiding this comment.
Reviewed the PR locally.
corepack yarn install --immutable finished with existing peer warnings, and corepack yarn build completed successfully. Docusaurus still reports repo-wide broken-anchor warnings, but I did not see new broken route/relative-link failures from this EVM docs section.
I left one inline factual correction around LSP26 batching. Otherwise the structure is solid for the SEO/GEO onboarding goal.
| | Can another app read follows? | Only if it integrates that app | Yes, through standard functions | | ||
| | Is profile metadata standardized? | Usually separate | Yes, through Universal Profiles | | ||
| | Can profiles receive notifications? | App-specific | Yes, through LSP1 integration | | ||
| | Can follows be batched? | Depends on app | Yes, LSP26 supports batch functions | |
There was a problem hiding this comment.
This looks inaccurate against the current LSP26 docs. The standard page lists follow(address), unfollow(address), reads/counts, and events, but I don't see batch follow/unfollow functions exposed there. For an SEO entry page this should probably be changed to something like "Depends on the caller/app batching transactions" unless there is a concrete LSP26 batch API we can link to.
There was a problem hiding this comment.
the factual premise is wrong against the current standard docs. The live LUKSO LSP26 page lists followBatch(address[] memory addresses) and unfollowBatch(address[] memory addresses) under Core Functions, and the LSP-26 spec also includes both batch methods. So I would not change the claim to “depends on caller/app batching transactions”; that would be less accurate.
There was a problem hiding this comment.
|
hey @JordyDutch, @LUKSOAgent has blessed this :). If all good let's get this out cause will take some time for search engines to index it all. |
|
@JordyDutch seems like a failure on cloudflare side. @LUKSOAgent are you capable of debugging this? |
|
@CJ42 @frozeman I addressed the feedback you've forwarded through @JordyDutch. I understand it but want to point out that forgoing an EVM Builders section w/ standalone articles in the way I previously had it misses out on significant SEO gains. It does not sacrifice it completely, but it materially reduces the long-tail capture strategy. Which is lost future organic opportunity. The removed EVM section had:
The current integrated version has:
So the raw footprint shifted from a broad SEO content hub to targeted enhancements inside existing docs. Where SEO Is LostThe biggest loss is not “Google dislikes the restructure.” The loss is that we removed dedicated pages for long-tail search intent. Right now we don't rank on any of the high intent queries EVM builders would use to search for solution to their problems. Literally nowhere to be found in the results. A standalone page titled How to Add ERC20 Transfer Hooks on EVM has a much cleaner chance to rank for:
A subsection inside Migrate ERC20 to LSP7 can still rank, but it is less exact-match, less focused, and less likely to satisfy a user who is searching the generic EVM problem before they know they care about LUKSO. The largest reason is page-level intent matching. A page titled How to Add ERC20 Transfer Hooks on EVM has a clearer shot at ranking for that query than a subsection inside Migrate ERC20 to LSP7. Google can rank sections, but titles, headings, URL paths, internal links, and focused content still matter. Google’s own docs emphasize clear titles, useful content, internal linking, and canonical consolidation:
Same issue applies to:
Those were discovery pages. The integrated version is better for users already navigating LUKSO docs, but weaker for developers searching broad EVM pain points. Where SEO Is PreservedThe restructure preserves the strongest LUKSO-specific and migration-specific searches:
Those are now on canonical docs pages with better titles/descriptions and structured data. |
|
@CJ42 @frozeman what if we didnt include the "EVM Builders" in the topbar but still made it accessible by directly navigating to those links? We'd make it discoverable by search engines, but not through the site. This way we can test to see if the SEO strategy is working when it comes to attracting new builders without sacrificing the "aesthetics" of the docs. |
3 participants
We’re adding an EVM-builder layer to the docs to improve SEO and GEO by answering the questions developers already search for or ask AI tools: ERC20 limitations, NFT metadata, receiver hooks, token discovery, smart-account permissions, gasless execution, and ERC1271 signatures. Instead of relying on builders to already know LUKSO terms like LSP7, LSP8, ERC725Y, or Universal Profiles, the new pages map familiar EVM problems to the LUKSO standards that solve them.
This helps LUKSO become more visible in organic search results and generative AI answers without changing the existing docs. The current documentation remains the technical source of truth, while the new section packages that depth into clearer, query-aligned pages that can rank, be cited, and guide builders from a known ERC problem into a practical LUKSO implementation path.
