The problem you are encountering is due to fragmentation. When a file is written to disk, it is not always stored with all of its contents in a row. Whenever you delete a file, it frees up some blocks on disk, but there may be another file right after it. This leaves a chunk of free space that is as big as the deleted file (rounded up to the nearest cluster size). If you then write a file that is bigger than the deleted file, it may get written to that block, but only as much as fits, with the rest being written to the next available free block. This file is now fragmented.
Most people think of disk fragmentation as being bad for performance, but the truth is, it is far more problematic and troublesome for data-recovery. When you lose a file and need to recover it, if the file is not fragmented, then all you need to do is to find the beginning of the file and know its size. Then you can simply copy the appropriate number of clusters. This is made easier when using file signature which are usually stored in the header (i.e., at he start of the file). Therefore, all you have to do is to scan the disk, looking for patterns that indicate the beginning of a file, and then copy a certain number of blocks to recover the file (usually resulting in some extraneous junk at the end of the file; but that’s better than nothing).
If the file is fragmented however, it becomes much more difficult to recover the file because without the file-system information telling you where each chunk of the file is stored, there is no way to know which clusters belong to which files. You may be able to find a file and get a part of it, for example the first 15MB that happen to be stored in a row, but then that last 1MB may be stored somewhere else and there’s no way to know that.
If you are trying to recover a text-file, you may be able to manually locate the separate pieces scattered around the disk and stitch them back together, but even that is difficult if you happened to be editing the file and saved several times, making changes each time. How do you know if the next piece is from the latest version of the file or from an earlier piece? It is possible, but quite time-consuming. Most binary files on the other hand are flat out impossible to recover if they are fragmented (I suppose you could find pieces of certain types of binary files like MP3s in which even fragments can be “viewed”).
Keeping your disk defragmented makes data-recovery much easier. Unfortunately, due to the limited write-capability of SSD drives, many people are actually defragmenting less, which puts data at more risk of being permanently lost.
Let’s say that your files are stored on disk as shown below. The purple clusters are where your file is stored. The first 15MB of the file are stored in a row, but the last 1MB is stored separately, earlier on the disk. The yellow line shows the beginning of the file where the PDF signature was found. The program found the signature and identified a PDF file, but was only able to copy the first 15MB before finding another file. It has no way to know where the last 1MB is located because the cluster chain is, or rather was stored in the file-system.