SEO Strategies for User-Generated Content Platforms

I operate a technical information sharing service called Zenn. I anticipate that for the long term, a significant portion of Zenn's traffic will come from "search." In fact, I believe it should be a service that receives a large amount of search traffic.

Articles filled with specific source code or mathematical formulas are rarely shared on social media. Unless the content is somewhat abstract, the readership remains limited, and it demands significant effort from the reader.
(Although there are some "super" individuals who can write articles that gather attention while including specific details.)

However, when I face a problem at work, what usually helps me are articles containing specific code or niche experiences from people who have actually encountered that problem. They might not reach many people immediately, but I hope this place becomes a collection of wisdom from predecessors that helps those who walk the same path later.

Information Sources for SEO

Before diving into the main topic, I would like to introduce the SEO information sources I refer to. There are countless articles that pop up when you Google things like "SEO theories," but be careful because some introduce techniques that are no longer effective at all (e.g., "meta keywords improve search rankings!").

Personally, I find the following two sources very helpful:

1. Search Engine Optimization (SEO) Starter Guide: This is the official guide by Google. You can grasp the basic terms and knowledge you need for SEO.
2. Overseas SEO Information Blog (in Japanese): This blog discusses SEO primarily based on comments from Google employees and official announcements. Having been running for over 10 years, the insights are highly valuable.

Moz's blog, one of the largest SEO companies in the world, also conducts its own research, which is interesting. However, basically, you can gain sufficient knowledge just by checking the two sources above.

By the way, reading the paper written by Google's co-founders (1998) is quite fun, as it touches on Google's early algorithms.

SEO for UGC

Since this is my first time building a User Generated Contents (UGC) service, I am using trial and error for SEO. I will write about what I am practicing at Zenn here, but everything is still a work in progress. I will add or correct information as I learn more.

0. Premise

The most important point for ranking high in search results is the quality of the content. Google announced in 2019 that it adopted the natural language processing model BERT, and I believe the impact of content itself on search rankings will continue to grow.

For a UGC site, controlling the content itself is extremely difficult. There aren't many proactive SEO measures that a service operator can take, so it is more about implementing measures to prevent penalties.

1. Preventing Abuse of Links

On a UGC site, all links that users can post should have the rel="nofollow" attribute specified.

<a href="~" rel="nofollow">Anchor Text</a>

By specifying this attribute, you can instruct search engines not to follow the destination link. SEO agencies (and individuals) are constantly searching for places where they can post links with SEO benefits on sites they want to rank higher. If a site allows unlimited links without rel="nofollow", many people aiming for SEO purposes will jump on it.

Of course, if it is a high-quality and relevant page, there is no problem, but there is a possibility that it could secretly be linked to fraudulent pages or adult sites. In such cases, if rel="nofollow" is not specified, there is a risk that Google will judge the origin site as being of the same type.

However, I believe it is important to include internal links so that search engines can follow and crawl related pages within the site. For this reason, links starting with https://zenn.dev/ do not have rel="nofollow" applied on Zenn.

2. Preventing Low-Quality Pages from Being Indexed

On a UGC site, the number of pages continues to grow. Especially right after launch, evaluation from search engines is low, so they do not actively crawl the site.

*In the case of Google, crawlers (=Googlebot) crawl (visit) each page on the site one by one and index (register) the page information.

Googlebot crawls tens to hundreds of thousands of pages per day for sites it trusts, but it does not spend that much cost on sites it is unsure whether to trust. Zenn is still a "site I'm not sure if I can trust" to Google. Therefore, it is necessary to make effective use of the limited crawl budget that Google allocates.

For this reason, we add a meta tag that instructs search engines "you don't need to index this" for low-quality pages.

<meta name="robots" content="noindex" /> 

Pages with this meta tag will be excluded from search engine indices.

So, what exactly are low-quality pages? At Zenn, we judged them based on the criteria of "things that would be noise if they appeared in a Google search = pages that you would be disappointed by and leave immediately after clicking." For example, the following types of pages:

• User pages with no posts yet
• Topic (tag) pages with no posts yet
• Pages for logged-in users (dashboards, account settings, etc.)

We plan to adjust these criteria while observing the situation going forward.

3. Preventing Duplicate Indexing

It is also important not to let the search engine index multiple pages with the same content. For example, if someone posts a link to a page on Zenn with a query string like /example?foo=bar. When the crawler follows the link, there is a possibility that /example and /example?foo=bar will be considered different pages.

Google seems to account for this to some extent, but we have confirmed even recently that pages with almost identical content are indexed separately.

Also, it is a problem if pages that have pagination are all indexed. (If pages 1 to n appear in the search results, they become noise. There should be almost no search users who want to "start viewing from page 3.")

At Zenn, we specify a canonical URL for almost all pages that we want to have indexed.

<link rel="canonical" href="URL" />

With this, even for pages where multiple URLs exist, the evaluation can be consolidated into a single URL. One thing that should especially not be forgotten is search result pages. /search?keyword=example, /search?keyword=exampl, /search?keyword=exam, and so on; infinite pages are created by the number of keywords. For pages like these, it is necessary to take measures such as excluding them from indexing or specifying the canonical URL as /search.

4. Optimizing the title tag

I think this is a point that needs no explanation. The title tag directly affects the title in search results and is also displayed in browser tabs, bookmarks, etc., so it is important from a user experience perspective. Even for pages that do not need to be indexed by search engines, they should always be displayed.

Since it can be cut off if the title character count exceeds a certain limit, which might make it difficult for users to grasp the content, I have set strict character limits for titles, even though I feel bad for the authors. It was a judgment call that it is better to set limits and have the authors accommodate them than to have them cut off in places the authors did not intend.

However, at this moment, we treat alphanumeric characters and Japanese characters as the same single character, so I think adjustments are needed. For example, a title like "RangeError: Maximum call stack size exceededエラーが発生したときの対処法" (How to handle the RangeError: Maximum call stack size exceeded error) would quickly run out of character space.

Also, to prevent the title tag from becoming too long, I recently removed the string "Zenn" from the title of post pages (<title>Title｜Zenn</title> 👉 <title>Title</title>). Although, it seems Google sometimes takes the initiative to automatically add "Zenn" to the search results anyway.

5. SSR (Server-Side Rendering)

At Zenn, we use SSR for pages that we want search engines to index. Since 2019, Googlebot has been rendering using the latest Chromium, so there are no major issues with SPA from an SEO perspective.

However, there are still some areas where SSR is better.

SPA index slower

With SSR, pages are indexed by search engines immediately, but with SPA, they enter a rendering queue and are not indexed in their complete state until Googlebot's resources are available.

📄 How Googlebot processes JavaScript →

This might be a negligible point, but disadvantages like becoming harder to be featured on Google Discover are conceivable.

SPA rendering is harder to grasp

With SPA, it is not clear at what point in time the page information is judged by Google as being "the content of the page." For example, if the "Loading..." display is long, the content of the page might be judged as just "Loading."

Google's official documentation states the following (I have loosely translated the original English since the official Japanese text was a bit difficult to understand):

Crawlers may understand JavaScript, but there are often limitations worth being aware of in how they render. Client-side rendering can work but often not without additional testing and leg-work.

In the case of SPA, you have to verify how it is actually rendered by Googlebot using the Mobile-Friendly Test or the URL Inspection tool in Search Console.

On the other hand, with SSR, you only need to read the source code and confirm, "Okay, it's displayed properly."

6. Prepare a Sitemap

While crawlers will follow links to patrol the site, they might not reach pages that are buried deep. Therefore, by preparing an XML sitemap and registering it in Search Console, we convey the existence of pages to Google.

Currently, Zenn includes the following in the XML sitemap:

• Top page
• Post pages
• Topic pages

We plan to add user pages in the future.

7. Collect backlinks

Backlinks are clearly still effective for SEO today. The more links you get from external sites to zenn.dev, the higher the evaluation of zenn.dev (provided the rel="nofollow" attribute is not attached; links from Qiita, for example, have no effect...!).

Basically, the main policy is to operate the service properly and wait for backlinks to increase naturally. However, I think the following measures can also be effective:

• Prepare a media kit page to make it easier for others to link to us (Zenn's Media Kit)
• Issue press releases on platforms like PR TIMES during releases to target backlinks from web media

Since Zenn has not issued press releases, we currently have almost no backlinks from media outlets. If we were operating as an organization, I think it would be fine to carry out measures to increase exposure, but as I am currently developing it alone, the policy is to dedicate all resources to improving the quality of the service itself.

Other SEO Measures Under Consideration

Although not implemented at the moment, I am also considering the following SEO measures.

Specify Meta Descriptions

Currently, Zenn does not specify meta descriptions (<meta name="description" content="Page description">) on article detail pages. Meta descriptions may or may not be used in the page description on search results.

While it is said that meta descriptions do not have a direct impact on search rankings (Reference), they are important because they affect click-through rates when displayed in search results.

The issue is that it is a high hurdle to ask users to input a "summary of the post" on a user-generated content site. Specifically, it could raise the barrier to entry for posting, or users might write summaries that were not what we intended.

While Medium and Qiita seem to use the beginning of the body text for meta descriptions, I thought that on Zenn, the "beginning of the body text = summary of the article" is often not the case, so I have decided not to set meta descriptions at all.

However, as the number of articles has increased, I have been thinking about trying out the "use the beginning of the body text for the meta description" method once things have settled down. Ideally, it would be great if we could automatically generate summaries using invincible deep learning.

Set up Breadcrumb Lists

Breadcrumb lists are important for conveying the structure of the site and the relevance between pages to search engines. For example, if you set up a breadcrumb list like "Home > Flutter > Post Page," it becomes clear that the post page is related to Flutter.

The problem is that while multiple topics (tags) can be attached to a single post, only one breadcrumb can be adopted by Google.

📄 Is it a problem for SEO to place multiple breadcrumb lists on one page?

Ideas to address this include:

• Adopt the first specified tag for the breadcrumb list (Qiita likely does this)
• Perform a slightly larger grouping that serves as categories in addition to tags (should be done automatically so as not to increase the burden on users)

These are possibilities, but in any case, dealing with this is likely a task for later.

---

I have written quite a bit, but I may have overlooked some measures. If anyone has any expertise, I would be happy if you could let me know in the Discussions section of this page!

👇 The following article, which was written previously, is also very helpful.
Thinking about Zenn's SEO