Hi Ghost team! I have an application that uses NextJS and would love to use Ghost CMS as the blog portion of my application. I’d rather not design my own blog layout from scratch (so I wouldn’t want to use Ghost as headless CMS) and would like to use a custom theme, like the ones found on the Ghost marketplace, instead.
Here’s the kicker, I would like to host my blog at a url such as https://myapp.com/blog, and blog posts in a URL such as https://myapp.com/blog/post-1.
I could run the blog on a subdomain like https://blog.myapp.com and simply point a CNAME at my Ghost URL, but I’ve heard there are SEO implications for doing such a thing, which is why I’d prefer to run on a path of my app domain instead of a subdomain.
Is it possible to do something like this when using NextJS? I discovered there’s a rewrites property in the next.config.js to re-route a path to an external URL (like the URL of my hosted Ghost webpage), but wasn’t sure if there were any implications in doing something like that?
The admin domain doesn’t need to be associated in a path on my app, just the home page / blog posts (aka user facing pages).
Is something like this even feasible? Thanks for any insight!
@vikaspotluri123 Is there some trick to getting around DNS errors when using rewrites with nextjs apps? This method leads to an error page indicating DNS error when I attempt it. Ghost blog is hosted by Ghost in this case at [slug].ghost.io.
I’m not super familiar with Next, but my first thought is Ghost (Pro) doesn’t know your custom domain, so it’s returning the DNS error since it’s not routeable.
I’m not sure if you’re able to setup a custom domain on Ghost (Pro) without Ghost (Pro) actually hosting it, but if you can, that would fix your problem
otherwise, you have to rewrite to [slug].ghost.io, and do URL replacement ([slug].ghost.io → slug.website)
@vikaspotluri123 Sorry I’m not sure my “slug” example was clear.
Using the same approach of rewriting
https://myapp.com/blog to https://myapp.ghost.io
https://myapp.com/blog/:path* to https://myapp.ghost.io/:path*
I am getting these errors regarding DNS saying:
Domain Error
Failed to resolve DNS path for this host
The author of this post discusses using this technique of using nextjs rewrites and pointing to the “hosted” ghost webpage but I suppose that doesn’t indicate who is hosting it.
Given this additional context, might you know of some change in configuration or using the rewrites that might allow me to use nextjs rewrites to point at a Ghost Pro hosted webpage from the nextjs app?
I think there’s something wrong with the Host header that’s being sent for the proxy. It looks like you’re getting https://error.ghost.org/ which happens when you access a Ghost (Pro) site that doesn’t exist
To serve a Ghost(Pro) site from a proxied subdirectory URL requires additional domain configuration, which is an addon that’s available on the business plan.
An alternative approach would be to pull in all content from the Ghost Content API at build-time and then build those pages statically and serve them directly from Next, which is what most people do in a headless setup.
@John Is there a way to use the Ghost Content API to build statically using the styles configured via Ghost instead of in the Next app? We don’t have a requirement to customize the theme in code and would rather leave it to the content team to manage via the Ghost Admin page, but want the benefits of having the blog under a subpath for SEO.
Alternatively, is there a way to have the domain configuration add-on at a billing level less than business?
You can copy across styling from a Ghost theme to a Next frontend and achieve essentially the same results with relative ease — but the domain config addon is only available on the business plan (it’s a lot of work to support)
It might be worth mentioning that SEO benefit of subdir vs subdomain is dubious in 2022. We moved the Ghost blog from blog.ghost.org to ghost.org/blog a few years ago and saw no change in rankings at all.
It’s certainly possible to have a setup like this work well, but in the majority of cases the complexity and fragility of the configuration isn’t worth the effort
You might have to do some tweaks to different configs to get it to work.