The content lifecycle starts when somebody first drafts a page and runs until the page comes down. Most of it sits after publication: who is answerable for the page still being right, how often somebody looks at it again, and what happens once it has stopped being useful. Those are decisions the organization has to make because a page left untouched goes on saying what it said the day it was published.
Who is answerable for a page being accurate
The person answerable for a page being accurate is the content owner, and SharePoint has no field for it. What the platform holds about a page is its version history, which records who changed the page and when, and nothing about who should have made the change.
Accountability for an area’s authors sits with the area that publishes, and the intranet team keeps the right to require a page be corrected. That split holds after publication as well as before it. The area answers for its pages still being right, and the intranet team can require a correction without being the party that writes it.
Our view is that most content pages should carry a named content owner, although perhaps news content is the largest exception. A news post records something that happened on a date, and a year later it still reads correctly as that. A page describing a process, a benefit or a policy makes a claim about how things are now, and that claim is what goes out of date, hence the need for a named content owner.
How often a published page gets looked at again
A check on a published page means somebody opening it, comparing what it says with how things stand today, and either correcting it or confirming that it is still right. Our view is that the publishing standard should set the longest a page can go without somebody doing that, and leave each area to work to a shorter interval where its own content deserves one.
What that outer limit should be depends less on the type of page than on what it costs to have the page incorrect. A page describing how to book leave gets read by somebody who is about to act on it, and a page describing the history of the organization does not, so one interval across both is either more work than it is worth or not enough.
SharePoint holds no review date on a page and has nothing that notices when a date has passed. An interval therefore lives wherever the area chooses to keep it, and it holds for as long as the area’s own management expects people to keep to it.
Content Manager Dashboard, one of our solution, doesn't add a review-date field SharePoint doesn't have, but it does put page status across several sites in one place for the people responsible for reviewing them, including custom columns an organization has already added for that purpose. It can serve as an inventory and action layer on top of whatever review cycle you decide on.
What page scheduling does
Scheduling sets a go-live time on a page. A site owner enables it on the Site Pages library and an author then sets a publish date and time on an individual page, and where page approval is configured the page still has to be approved before it publishes. Out of the box, SharePoint has no matching end date, no field for when a page should come down, and no setting that asks anybody to look at the page again.
What happens to a page at the end of its life
The area that published a page is best placed to say when it has stopped being useful, and the intranet team can require the question be answered rather than answering it. What then happens depends on the organization. Some keep everything and others are happy to delete.
SharePoint offers two actions on the page itself and neither is an archive. A page can be unpublished, which returns it to draft, though Microsoft records that an unpublished page still appears in search results unless the permissions on it change as well.
Deleting a page sends it to the site Recycle Bin, and deleted items are kept for approximately three months across the first stage bin and the second stage site collection bin together. Restoring a page does not affect its version history.
Demoting a page with Copilot in SharePoint
Copilot in SharePoint carries a capability for improving a site that lists inactive pages and offers to demote them. Demoting a page deprioritizes it in search and agent results and adds a banner saying the page is not maintained. The URL stays live for anybody who goes to it directly, and the action can be reversed. Using the capability needs a Microsoft 365 Copilot license.
Microsoft describes this as retiring outdated pages and documents the action as Demote. Demote is the accurate word, because a demoted page is still published, still reachable and still says whatever it said. We’re hoping this feature becomes available in a non-Copilot context too.
Inactive site policies work on a whole site
Inactive site policies are part of SharePoint Advanced Management. A policy of that kind watches for sites with no meaningful activity and acts after three monthly notifications to the owners. The available actions are to do nothing, to set the site read-only, or to archive the site through Microsoft 365 Archive, a lower cost storage tier for content nobody is using, after a mandatory read-only period. No policy of this kind deletes a site.
The signals a policy counts include viewed and edited files and viewed pages, among others in SharePoint, Teams, Exchange and Viva Engage. That page views count is worth knowing, because a site whose pages nobody has updated in three years stays active for as long as people keep reading them.
Where the mechanics stop short
The absence of a page review date compounds a second absence. What SharePoint records about a site is a permission group, called Site Owners, and what it records about who is answerable for a page is nothing at all. So there is nobody the platform could notify and no date on which to notify them, and both halves of a review cycle sit outside the product.
The controls that do exist work on sites, and an inactive site policy will find the site nobody visits. A site people visit every day can hold pages that stopped being accurate two years ago, and no report in the SharePoint admin center will point at one of them.
Common questions
How often should intranet content be reviewed?
There is no single right interval, and the useful way to set one is by what it costs to have a page wrong rather than by the type of page. A publishing standard can set the longest any page should go without being looked at, with each publishing area working to something shorter where its content deserves it. Nothing in SharePoint tracks a review date out of the box, so an interval is kept by the people who publish or it is not kept at all.
Can you set an expiry date on a SharePoint page?
Not natively. Scheduling on the Site Pages library sets a go-live date and time, and Microsoft documents no matching end date and no page-level review or expiry workflow for modern pages. A page can be unpublished or deleted by hand, and Copilot in SharePoint can demote it.
Who is responsible for keeping intranet pages up to date?
Our view is that it is the area that published the page, with the intranet team keeping the right to require a correction. SharePoint records none of this. There is no content owner field on a page, and version history tells you who last changed a page rather than who answers for it, so an organization that names owners for its pages keeps that list somewhere of its own.
How do you find out of date pages in SharePoint?
No report in the SharePoint admin center lists pages whose content is wrong, because nothing in the platform knows what a page ought to say. Copilot in SharePoint can list the inactive pages on a site and offer to demote them, which needs a Microsoft 365 Copilot license. Inactivity is not the same thing as inaccuracy, since a page nobody has touched for two years may be perfectly correct and a page edited last week may not be.
