Generator-jhipster: strategies and suggestions for SPA and SEO

[erikyuzwa]

Overview of the issue

While I understand from the outset that my issue is very likely NOT a jHipster issue, I'm not sure which domain it's actually in. And I'm pretty sure that if other jHipster users have to consider SEO at some point then they'd have come across the same challenges. I was hoping to just hear any suggestions or strategies that the jHipster community pursues for such a task.

SPA frameworks are usually all run and contained within a <div> (or other) HTML element within the index.html. As such, even when views / templates are injected / updated in the DOM from the SPA application, the surrounding structure (head, meta, body) structures have already been rendered and rarely update during the lifetime of the SPA session.

Work exists for some JavaScript frameworks trying to update / inject META information during SPA client runtime, but the approaches seem really hit and miss and some frameworks can have weird internal logic preventing you from making such changes at all other then just the title information.

If I'm generating a product page (for example), I'm not going to have that META information until I retrieve the product from within my SPA client --- are you seeing the rabbit hole? :)

• Creating a proper sitemap.xml for submission
• Updating page meta information, depending upon SPA view / request

Motivation for or Use Case

• We want to be able to have better ways to assist the google-bot (and others) for crawling our SPA to build an index
• As a result, we want to improve the quality / output of our meta information that search engines use to display in their results for our content

Reproduce the error

• it's not really a bug -- but a feature of SPA in general

Related issues

• couldn't see any - but maybe searched incorrectly

Suggest a Fix

• ??

JHipster Version(s)

latest

JHipster configuration

• Standard monolithic container
• Angular5 SPA (but it could be anything here IMHO...React or Vue or vanilla JS)

Entity configuration(s) entityName.json files generated in the .jhipster directory

n/a

Browsers and Operating System

• affects all browsers and OS configurations

• [x] Checking this box is mandatory (this is just to show you read everything)

[deepu105]

As you said this is not a JHipster issue, its an SPA issue in general. I'm happy to consider this a feature request if someone has a solution. I for one don't have any solution for this at the moment.

[jdubois]

I've done this for 2 different clients, and I've been willing to implement this in OSS for a long time, but I would need a couple of days for this (which I don't have). I'll try to explain what should be done, at least.

[erikyuzwa]

same here @deepu105 - too specific of an issue depending upon each environment to make a sane feature request. Thanks regardless.

@jdubois - I would love to hear any tidbits you can share, or advice on the approach you went with. I've done this for clients on regular architectures, but I've never looked at this before now on the SPA side of things..

[jdubois]

Here's a quick summary of what needs to be done - I'll try do it at some point, but if anybody wants to volunteer he's most welcome.

• For both Angular and React, switch the router to use HTML5 pushstate (that means no more hashbangs in the URL).
• On the server side, create a Spring MVC controller that redirect all trafic coming from the Angular/React URLs to the "/" page.

The difficult part is that we need to know which URL should not be handled by this new Spring Controller:

• "/api", "/management", "/v2/api-docs", "/swagger-ressources", "/swagger-ui", "/h2-console" are used by the server, so they shouldn't be redirected
• "/app", "/i18n", "/content" are used to serve client resources, so they also shouldn't be redirected
• When using microservices, all the microservices routes shouldn't be redirected

Please note that those URLs won't be available as Angular or React routes anymore, so that might cause some issues for existing applications.

Now for the specific metadata tag you refer to, the trick would be to migrate the existing index.html file to a dynamic page, so the metdata tag could be dynamic. That would be a custom implementation, but it shouldn't be very hard to do.

[erikyuzwa]

thanks a lot @jdubois - I think that's a pretty good starting point myself. :+1:

[jdubois]

As always, no time to do this, but it doesn't look like too many people need it.... As this would also add a burden for existing users (as they will need to migrate), I don't think this is worth it for the moment.

Maybe we could discuss this again for our next major release (then, breaking stuff wouldn't be as important).

So I'm closing this, but my documentation above is quite complete, so if anybody is interested, I would gladly welcome feedback, and even a PR (we could keep it until the next release, this is on some part of the code that doesn't change much, so merging later isn't that bad)

[erikyuzwa]

agreed @jdubois - thanks for your patience in keeping this open as well as your insight on it. Once I've dealt with all my fires (which led me to making the original issue), I'd love to make a contribution if I can. :+1:

[jdubois]

Oh you're welcome @erikyuzwa - this is probably a good first PR to do. Even if I closed the ticket, feel free to do it - maybe we will merge it with the next major release only, but anyway I'm sure this is what we should do at some point in the future, using the hashbang in URLs should be a thing of the past.