umbracoDocumentUrl table not populating on save and publish

Questions
1

Issue,

Since applying a minor upgrade there or there abouts 17.6.2 have experienced issues publishing new articles on our website. This issue has persisted through to 17.7.1 which we are currently using.

We will publish an article, the link’s for that article will populate on the info tab.

The article will then appear on the website for a time.

However when something happens i.e. the app pool gets recycled over night for example, the links for that page, change to ‘This document is published but its URL cannot be routed’

I can fix it straight away by republishing the page, but the same issue will occur when the site bounces again.

When I publish the page, I monitor the [umbracoDocumentUrl] table in SMSS filtering by the guid for the node that I have just published, and nothing is populated for that guid in the table. (at all). Im pretty sure that it needs to do this in order for those urls to persist.

The table [umbracoContentVersion] does get updated when I save and publish by the way.

There are no error messages when click save and publish, nor are there any error messages in the logs folder.

I have reloaded the memory cache and rebuilt the database cache.

We did have an alert in the data integrity page a few weeks back which is been addressed.

That alert was:

Found 2 untrusted constraint(s). These indicate pre-existing data integrity issues that need to be resolved manually.

Untrusted constraints prevent the SQL Server query optimizer from using them and indicate that orphaned or invalid rows may exist. Resolve the underlying data issue, then re-trust the constraint with ALTER TABLE … WITH CHECK CHECK CONSTRAINT.

Foreign key FK_umbracoDocumentUrl_umbracoNode_uniqueId on dbo.umbracoDocumentUrl

Foreign key FK_umbracoDocumentUrl_umbracoLanguage_id on dbo.umbracoDocumentUrl

After addressing this issue, the app has been restarted etc and the alert no longer appears, but thought I would mention it as I do think it may be related.

All the articles that have been published past the date of applying the aforementioned minor upgrade need their URL’s rebuilding pretty much on a daily basis at least, older articles are fine.

We’ve turned on some debug messages in serilog. Every time we save and publish it generates one of these.

{“@t”:“2026-10-13T14:25:01.8338774Z”,“@mt”:“Could not remove the document url cache. But the important thing is that it is not there.”,“@l”:“Debug”,“SourceContext”:“Umbraco.Cms.Core.Services.DocumentUrlService”,“ProcessId”:27928,“ProcessName”:“w3wp”,“ThreadId”:56,“ApplicationId”:“bfa88084c1661e8236aca829eea83eda2a339d0f”,“MachineName”:“xxxxx”,“Log4NetLevel”:“DEBUG”}

Cant see anything else in the logs that are worth sending to you.

The CMS url is correctly present in the appsettings cms routing part of the config files.

Any suggestions would be great because Im tearing my hair out at the mo.

Thanks

2

Hiya!
This is an ongoing, very prevalent thing.
I’ll link some other known threads that are related and may provide some insight, hope this helps!

3

Hi @stephwillis1982nfu

As per this thread, can you make sure you’re not setting your instance to a subscriber role? It needs to be a publisher role to populate the umbracoDocumentUrl table.

Justin

4

Thanks Justin and everyone above, that sounds interesting, let me grab a coffee and have a go! I’ll let you know what happens shortly!.

5

Hi all,

To close the loop on this from the HQ side: the pattern described here (published pages that work at first, then lose their URL and return 404 after a restart or deployment, with no rows in umbracoDocumentUrl) matches a bug that is fixed for 17.8.0 and 18.3.0. It’s tracked in #23565 and the fix is #23943. It has come up in a few threads, so I’m posting the same note in each.

What’s going on
Since 17.4.2, a page’s URL is written to umbracoDocumentUrl only by the server that handled the publish, and that write was skipped whenever the server’s role was Subscriber. The catch is that the role decides which instance runs scheduled jobs, not which one serves the backoffice. So the instance your editors publish from can end up as a Subscriber, either through the automatic election or because it’s set in code. When that happens, every publish it handles is kept in memory but never saved to the database. The page works until the next restart and then returns 404. Republishing puts it back in memory, which is why it keeps coming back.

Until 17.8.0 / 18.3.0 is out
Check that the instance your editors publish from is not a Subscriber. If it ended up as one through the automatic election, registering it explicitly as SchedulingPublisher avoids the problem until you can upgrade. If your own code registers it as a Subscriber, that setup isn’t supported and you’ll need to change it, upgrade or not. The load-balancing docs say the backoffice server should be SchedulingPublisher.

After upgrading
The fix stops new publishes from being affected, but it does not repair pages that are already missing their rows. To repair those once, either:

  • publish with descendants from the root, on the instance that holds the publisher role, or
  • delete the UmbracoUrlGeneration and UmbracoUrlAliasGeneration rows from umbracoKeyValue and restart one instance that isn’t a Subscriber. This forces a full URL rebuild on start-up, which loads every document, so expect a slower first start on larger sites.

If you still see this after upgrading and repairing, please open a new issue and reference #23565.

6

Thanks Jacob, thats good news. We have one CMS on its own box, and two front end load balanced boxes for the front end. Previously we havent set up Subscribers and SchedulingPublishers explicitly, so I’m doing that right now to resolve the problem. Thank you for your support.

7

Sounds like a good setup for it: CMS server as SchedulingPublisher, the two front-ends as Subscriber. Once that’s in place, any pages that already lost their URL need publishing once more from the CMS server (publish with descendants from the root covers everything in one go).

8

I’ve implemented load balancing properly now and its working well, Thank you all