If the scheduled content is temporarily rescheduled, should the push be rerun?

Schedule the content that has been arranged to be published temporarily rescheduled, whether the push needs to be run again, the judgment basis is not 'how many times the date has been changed', but whether this document has been exposed to search engines in a formal state before the rescheduling. Only the content that has never been online and has never been in the site map queue is purely a background action; on the contrary, as soon as the push channel has passed its address, it must be run in the same order after the rescheduling; otherwise, the time seen by the search engine and the time displayed on the page will not match.

Which field is actually changed when the schedule is changed?

AnQiCMS's time factor is responsible for only one thing: to determine when content should be switched from background status to front-end visibility. The rescheduling changes this publication time, without changing the title, address, or content text. Therefore, the decision to reschedule the push is actually based on whether there has been a 'fluctuation from appearing to disappearing' in the front-end visibility before and after the field change.

If the original scheduled time has not yet arrived, the document has been sitting in the queue without making an appearance, then move the time forward or backward. There is no record of this address on the search engine side, so there is no need to cancel or resend any actions. It is a waste of effort to reschedule the push in this case.

Scheduled release and timed release are not the same state.

The document status is divided into several types such as formal documents, drafts, pending release, and recycling stations. Scheduled release falls under the 'pending release' section, not draft. The difference between the two is very practical: draft links with preview=true can only be previewed and should not be sent out through any push channels; pending release is the batch that has been scheduled and is waiting to be automatically converted into a formal document.

Before rescheduling, first check the status column to see which type it belongs to. If you mistakenly treat a draft as a scheduled post and change the time, you will find that it is not in the push queue at all; if you change the scheduled post back to a draft, you need to confirm that you have not put this address in the site map previously. Deleting a formal document is moving it to the recycling bin instead of a physical deletion, and if there are operation mistakes during the rescheduling process, you can roll back, which leaves a buffer for rescheduling pushes.

When is it necessary to reschedule the push?

There are three situations that require the push to be repeated. The first is that the document has already been converted to a formal state at the scheduled time, and then the time has been changed to a later one. At this point, it is already visible online, and the address may have been indexed; the second is that the address of this article has appeared in the site map file before, and even if the schedule is changed later, the distribution records of the map will not be automatically withdrawn; the third is that there is already a submission record of this URL in the link push queue, and it needs to be actively pushed again at the new time.

In order, rebuild the sitemap first, then send the active push. The sitemap manages 'letting the search engine know about this address', and the active push manages 'let it come as soon as possible'. Both steps point to the same moment, and the time on the index side will be consistent.

What effect does changing the publication date have on inclusion?

The visible difference brought by the rescheduling is mainly on the time factor: if there is a deviation between the time displayed on the page and the time indexed by the search engine, the date shown in the abstract will not align with the list within the site. Moving the content to a future time will result in a shorter front-end list in the short term and a slight fluctuation in the amount of content indexed, which is a normal phenomenon; moving it back to the past is equivalent to releasing the queuing content all at once, and sending the links in batches is more stable than sending them all at once.

Do not change the title or pseudo-static address by default on the day of rescheduling. The time can be moved, but if the address changes, it is a different matter, requiring additional redirection handling, and the cost is not the same level as simply rescheduling.

Common questions

Will the records pushed before the rescheduling be invalid?

The push records themselves will not be withdrawn, it is just a submission. The meaning of re-running is to submit the same address again, so that the crawling plan can be rescheduled to a new visible time.

Should I resubmit many articles one by one?

No. After bulk rescheduling, first rebuild the sitemap as a whole, and then push the affected addresses in one go according to the queue, which is more efficient than pushing one by one, and it is also not easy to miss.

What should I do if the scheduled content does not automatically convert to official at the appointed time?

First, confirm that the time factor setting is consistent with the server time zone, then check if this article is still in the pending publication status. If it has been mistakenly deleted, it can be restored in the recycle bin, and then verify the publication time after recovery.