-
|
I noticed that for docs I can set both a frontMatter For blog posts the behaviour is different, the frontMatter Is this (inconsistent) behaviour intended? In my case, the problem is that the For example: Should I worry about the SEO limit? If so, is there a solution to adjust the code that generates the |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 11 replies
-
|
For blog posts, we don't allow You can put |
Beta Was this translation helpful? Give feedback.
-
That makes sense.
I'm not aware of the internals, and JSX in the title might be tough, but I guess markdown formatting can be stripped out. Should I open an issue to keep track of this?
That was helpful. I added But the Is this acceptable? |
Beta Was this translation helpful? Give feedback.
-
|
What you put in head is what you get, you can also put any other It's not publicly documented but we have a theme-common React helper component. You can create your own and use it in MDX too. <PageMetadata title={title} />
export function PageMetadata({
title,
description,
keywords,
image,
children,
}: PageMetadataProps): JSX.Element {
const pageTitle = useTitleFormatter(title);
const {withBaseUrl} = useBaseUrlUtils();
const pageImage = image ? withBaseUrl(image, {absolute: true}) : undefined;
return (
<Head>
{title && <title>{pageTitle}</title>}
{title && <meta property="og:title" content={pageTitle} />}
{description && <meta name="description" content={description} />}
{description && <meta property="og:description" content={description} />}
{keywords && (
<meta
name="keywords"
content={
// https://github.com/microsoft/TypeScript/issues/17002
(Array.isArray(keywords) ? keywords.join(',') : keywords) as string
}
/>
)}
{pageImage && <meta property="og:image" content={pageImage} />}
{pageImage && <meta name="twitter:image" content={pageImage} />}
{children}
</Head>
);
} |
Beta Was this translation helpful? Give feedback.
-
|
I think we already support Markdown title for blog posts, but it's a best effort and the stringification does not support all Markdown/JSX constructs
I remember we added support to ignore inline code blocks in #4882 You can create an issue if you want, it's a known limitation we have on the blog. Unlike docs that is able to support both MDX content title (rendered) and This is because the MDX doc is not rendered "as is". When there's a
Maybe that's possible to solve, but I'm not sure how (maybe with a Remark plugin 🤷♂️ ) |
Beta Was this translation helpful? Give feedback.
-
How do I tell Docusaurus about it? Do I have to swizzle something? Add it to the config.ts?
This explains why in my case the
I see. However I think that a consistent behaviour with docs would be less confusing. In my use case this means the |
Beta Was this translation helpful? Give feedback.
-
You can import (or provide it with MDXComponents) any component you want in MDX, including ours, yours, and our import {PageMetadata} from '@docusaurus/theme-common';
Yes, that would be better although not sure how to handle it. |
Beta Was this translation helpful? Give feedback.
-
|
If the SEO definitions for |
Beta Was this translation helpful? Give feedback.
-
|
I don't think there's a size limit, it's just a recommendation. A 65char title here and there is IMHO perfectly fine and I wouldn't like to pollute the Docusaurus logs just for that. It's not the responsibility of Docusaurus to emit such SEO warnings. There are dedicated SEO tools such as Ahrefs, SEMrush and many others that can monitor your site and advise you. |
Beta Was this translation helpful? Give feedback.
-
For the record, these tools are not free. |
Beta Was this translation helpful? Give feedback.
-
|
I personally use Ahefs for free on my website and Docusaurus website. Free plans are limited but are still doing much more than warning about a 60char title limit. There are probably free oss tools you can use. The point is, validating SEO is not related to static site generation, it can and should be plugged from the outside. |
Beta Was this translation helpful? Give feedback.
-
|
I did some experimentation and decided on a workaround, but it does not cover the Home page and I consider it quite kludgy. I added two Basically this is to avoid appending the suffix This was not exactly easy, given that the site is actually a collection of 20+ sites, with more than 500 pages. The solution required some sed & awk magic. However, I did not find a workaround for the Home page; I could not add a Any suggestion how to customise the Home page title (actually to remove the site title suffix)? I saw that you have a configuration option to configure the separator used in the title (to a dino!). I think an even more useful configuration option would be to completely disable the suffix. |
Beta Was this translation helpful? Give feedback.
-
|
You don't need to add twice the <head>
<title>{frontMatter.title}</title></head>
<meta property="og:title" content={frontMatter.title}/>
</head>But again if you setup the MDX component, you could just write
For Markdown you can write a remark plugin that does it automatically for you by adding extra You can also use the
It's the same: https://docusaurus.io/docs/docusaurus-core#head
In both cases you can override the title, or any other meta, to what you want.
Agree this titleDelimiter thing is quite annoying and we should change this. see also issue #5878 Our lib has a concept of |
Beta Was this translation helpful? Give feedback.
-
|
I think that now I have an acceptable solution. In case someone has the same problem, here is a recap: DocsI have a set of 20+ documentation webs, for related projects, all generated from the same template. Since sometimes I work with more of them in parallel, I found it necessary to have the project name explicitly mentioned in the documentation pages, for example How to install the xPack GNU Arm Embedded GCC, instead of Install Guide, as the menu & sidebar items read. Using the default Docusaurus logic, the resulting SEO title is How to install the xPack GNU Arm Embedded GCC | xPack GNU Arm Embedded GCC, which is long and redundant. Since docs allow both frontMatter title and H1 headers, I defined the frontMatter With this configuration the page title is the long explicit string and the SEO title was shortened to Install Guide | xPack GNU Arm Embedded GCC. PostsThe blog posts are mainly used to announce releases, and the titles look like xPack GNU AArch64 Embedded GCC v13.3.1-1.1 released, which is the desired string to be displayed in the page, in the Archive, in atom/rss, etc. Using the default Docusaurus logic, the resulting SEO title is xPack GNU AArch64 Embedded GCC v13.3.1-1.1 released | xPack GNU Arm Embedded GCC, which is way too long and redundant. Since for posts currently it is not possible to define separate frontMatter titles and H1 headers, the solution was to add a custom frontMatter With this configuration the page title is the long explicit string and the SEO title was shortened to Version 13.3.1-1.1 released | xPack GNU Arm Embedded GCC. I could not find instructions in the Docusaurus web site how to provide it with MDXComponents, so I imported it in each blog post. The top web site is: It would be really nice for Docusaurus to support both frontMatter titles and H1 headers for blog posts, it would make these use cases simpler. |
Beta Was this translation helpful? Give feedback.
-
|
Note: technically you don't even have to modify your source docs. You could swizzle BlogPostItem and use Even better, you could swizzle
|
Beta Was this translation helpful? Give feedback.
-
I think we could add a new |
Beta Was this translation helpful? Give feedback.
For blog posts, we don't allow
# titlebecause this would enable Markdown/JSX in it, while we need the title to be a pure string that we can use on other places such as the paginated list, the sidebar, the RSS feed entries... It's a technical constraint we currently have although we might try to solve it later.You can put
<head><title>My SEO title</title></head>in any MDX file to override the default meta SEO title.