Thanks Sid, as I kind of expected you have done your routing very similar to mine with some minor differences, but also have an end result of prefixed forward slash or not both going to the same page which is a potential SEO issue if some backlink partners decide to backlink with or without, and the SERPS see it as 2 unique URLs.
Personally I am not sure if the entire issue is actually resolved just by making sure a canonical tag is used for every page that explicitly tells the SERP which URL you want to use, as that can not change either way.
Even in that article i linked to, they noted that javascript frameworks with routing work a bit different from the other ways like wordpress / htaccess
@ben, I know you take SEO as seriously as me, can you give me your thoughts when you have a gap.
I don’t know the SEO implications, but I’ve had success parsing the URL when it doesn’t match a route and rerouting via a 301
For large sites, a DB lookup often happens for a server-side rendered 301 page (as anything else might be seen as a malicious redirect by modern browsers)
The way I think of it is instead of giving the user/crawler a 404-type response when they go to the non-setup route, they’re 301’d from site.org/route to the correct route as I define it site.org/route/
This may be poor practice for SEO; in our cases we just wanted it to work for users typing in the URLs
Came to this solution after reading your comments, don’t know if is 100% correct but seems to work:
Inside extensions/server_connect/routes I placed a file called nonslash.js:
exports.handler = function (app) {
app.use((req, res, next) => {
// Check if the path ends with a slash and is longer than 1 character
if (req.path.endsWith('/') && req.path.length > 1) {
const query = req.url.slice(req.path.length);
const newPath = req.path.slice(0, -1) + query;
return res.redirect(301, newPath);
}
next();
});