Why does disabling Pretty URLs not disable Pretty URLs?

Why does disabling Pretty URLs not disable Pretty URLs? I’ve turned the feature off in Site Configuration > Build & deploy > Post processing > Pretty URLs. When that had no discernible effect, I added a netlify.toml file to the root of my site (unruffled-sinoussi-fbd7d8.netlify.app, primary domain: tinyapps.org) with [build.processing.html] followed by pretty_urls = false to no avail.

To redirect extensionless duplicates to their corresponding .html files, I’ve been instructed to use canonical tags or Edge Functions, but would prefer to simply disable the feature altogether for simplicity’s sake.

1 Like

Hi, @miles. It looks like it is working to me. This is the a section of the HTML I see when I curl the site:

<ol start="0">
<li><a href="/network.html">network</a></li>
<li><a href="/text.html">text</a></li>
<li><a href="/graphics.html">graphics</a></li>
<li><a href="/system.html">system</a></li>
<li><a href="/file.html">file</a></li>
<li><a href="/misc.html">misc</a></li>
<li><a href="/palm.html">Palm OS</a></li>
<li><a href="/macos.html">macOS</a></li>

The <a> tags above do have .html in the link. When I click those links, the new URL in the address bar retains the .html file extension:

To summarize, it does appear you have disabled “pretty URLs” successfully when I test. If you are seeing something different when you test, please let us know.

Thank you for your fast and kind reply, @luke. Both .html files and their corresponding extensionless versions continue to work in my testing; for example, both tinyapps.org/blog/202208280700_word-calculate-days-between-dates.html and tinyapps.org/blog/202208280700_word-calculate-days-between-dates lead to the same content, causing search engines to index them separately. Here’s an example from Kagi which returns both pages: kagi.com/search?q=Microsoft+Word%3A+Calculate+number+of+days+between+two+dates.

@miles There is some more information here:

Thank you, @nathanmartin. I read the document but am still unclear on whether there is any way to prevent .html-less duplicates from being created and served. Do you know of any such way please?

1 Like

@miles As I understand it, there is no setting for what you’re requesting.

If you’re trying to having the .html extension showing, (which is the opposite of what most people want), then you may be able to use a redirect to push from a path like /file to /file.html

1 Like

Thank you, @nathanmartin. Yes, I’d prefer having the .html showing, just like other hosted file extensions (PDF, TXT, ZIP, etc.). As for using _redirects (which would be swell), in another thread I was informed that it would not work, and to use rel=canonical or Edge Functions instead.

It’s easy enough to add the canonical tag to static pages, but I’ll have to tweak my blog publishing routine a bit to dynamically add the corresponding filename into each HTML page.

Was just hoping there was a way to stay standards-compliant and reduce overhead (even the extra ~100 bytes taken by each new link tag ;-).

@miles I’ve not tried myself so the reality may be different, but the redirects playground indicates it would work.

The rules would need to be manual though.

For anything more advanced you’d have to try an edge function as the others suggested.

Thank you, @nathanmartin. Yes, I have no doubt that should work; I use _redirects for several dozen static links at present. Do you know if there is any upper bound on the number of lines in _redirects? I’d need to add around 1,500 initially (which could be done very quickly by pairing a directory listing with a simple regex).

Edit: Just stumbled onto this quote from @luke:

For example, if you have only twenty (20) rules, the impact to the site shouldn’t be noticeable. If you have a thousand (1000) rules, this may start having an impact on site performance.

Hi, @miles. This topic is a duplicate of this topic you created recently:

Please do not create duplicate topics as this makes the support forum less useful to others, it creates unnecessary work for our support team, and it just slows down our responses.

About the upper bounds for redirect counts, there is nothing documented officially. I would recommend, for performance reasons, to limit the number of redirect per site to 2000 or fewer.

Sorry, @luke. I did not intend it to be a duplicate, but a continuation. In the first submission, I was told to use rel=canonical or Edge Functions as a workaround, but did not have an answer to why disabling Pretty URLs apparently had no discernible effect. I was hoping to understand that better and apologize if it came across as a duplicate.

1 Like