In general, the process for web-based traffic is the following, assuming one step for the entire DNS exchange:
1. Client resolves the web server IP via DNS
2. FortiGate receives client SYN packet
3. A session is allocated
4. A routing lookup is performed based on the routing table (connected, static, and dynamic routes based on destination), in addition and subsequent to policy routes (policy routes are applied before the rest of the routing table)
5. Based on the source and destination interface and address, service, time of day, and optionally, user or device, a policy is matched, and logging, WANOpt, web cache, NAT, UTM, and disclaimer rules are applied.
Step #4 always happens before policy matching, so crafting a policy on its own will not guarantee egress out a certain port, only that traffic choosing that port already can be blocked. In this manner, though, it is theoretically possible, if you have perfect 50/50 non-random, alternating packet load balancing, that half the requests would exit the right port when they weren't denied by the policy created, or alternately, that didn't hit the implicit deny, but were allowed by the policy you mentioned.
The FortiGate doesn't load balance in this fashion, unfortunately, so a policy wouldn't work.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.