Based on the comment discussion, it appears that the ASPX-based website is not sending the correct headers.
SharePoint, like any web crawler (or browser/proxy cache), relies on certain headers being sent back to it in response to a valid GET request (as an aside, it doesn't do this for SharePoint content.
It simply asks itself for all the changes since the last crawl as SP maintains a change history for this purpose). For this to function correctly, one of two headers need to be present, an E-Tag header (which gives a yes/no answer to the modified question. It either matches or it doesn't) or the Last-Modified header (which informs the requester "when" the content was last changed).
In your first edit, you noted that plain HTML files (known as static files as they are read directly from the web server's storage and aren't "processed" like ASPX pages) are correctly ignored when incremental crawling. This is due to IIS reading the file's LastModifiedTime attribute and sending that in the Last-Modified HTTP header automatically without user configuration/intervention.
Note, these headers are easily seen when using your browser's
developer tools (or a tool such as Fiddler). If you look closely at a
request for a SharePoint page, it has a Last-Modified header too but
it'll be the current time unless you've enabled a form of caching
(such as page or output caching).
Regarding your ASP.NET pages, if you have access to the Response object, you should be able to set this header with the Response.Cache.SetLastModified(DateTime) method. See: system.web.httpcachepolicy.setlastmodified
Once set, verify that the correct header is being sent using your browser's developer tools.
Forgot to add: Determining what the "Last Modified" time is, is up to you.