-
Notifications
You must be signed in to change notification settings - Fork 396
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Defensive SEO Strategy for Gno.land #3910
Comments
Thank you @moul, for bringing this topic to our attention. I agree that UGC can pose a threat to our platform. It might be helpful if @kristovatlas could list the potential issues we could face, so we can determine the best ways to address them. I personally see some of them as: SEO bombing, dilution of site authority, scam, phishing attacks... Regarding UGC on websites, specifically metadata: on platforms such as Medium or dev.to (with rendered content), meta titles and descriptions are either derived from the H1 title/first paragraphs or are manually added in a dedicated field (e.g., in a CMS). But none of these approaches fully guard against scams or malicious content IMO. Also, let's keep in mind that SEO isn’t solely about title and description metadata, the page’s actual content typically plays a much larger role. While there’s no official or universally agreed-upon figure, we can estimate that around 30% of SEO impact comes from metadata, while about 70% is driven by the page’s actual content. Below are some ideas on how we might retain UGC in our metadata (thus improving SEO, UX, and accessibility) while still protecting gno.land:
These are just initial suggestions. I’ll keep researching other options to ensure both security and a positive user experience. |
Created this PR #3924. Then we can take more time to consider SEO optims. |
This reverts commit d1db75e (#3797). See #3910. Let's revert this now. Then we can try to improve SEO automatically by extracting the first H1 and the first paragraph, as this PR did manually. After that, we should take more time to consider aspects such as frontmatter and everything involved in allowing developers to specify "invisible" elements.
Gno.land enables permissionless content creation, and while we have moderation tools, SEO metadata is largely invisible and unlikely to be a priority. This creates a risk where bad actors could manipulate metadata to harm Gno’s reputation, making it crucial to focus on risk mitigation first rather than aggressive SEO optimization. A recent example is #3797, which introduced front matter support for custom metadata, improving visibility but also increasing exposure to potential abuse.
Before optimizing for search rankings, we need to ensure search engines can distinguish between Gno.land’s main pages and user-generated realms, preventing harmful content from affecting the platform’s reputation. Should we roll back or restrict some of the changes in #3797? How can we limit risk without restricting permissionless content? The priority should be protecting Gno.land’s credibility before considering any proactive SEO efforts. Let’s discuss.
The text was updated successfully, but these errors were encountered: